Sans me casser les pieds =E0 faire une cage (on verra plus tard), mais
pour =E9viter que Firefox ait le droit d'acc=E9der =E0 n'importe quoi s'il
=E9tait compromis, je me suis dit que ce serait mieux et assez simple de
le faire ex=E9cuter par son propre utilisateur.
J'ai cr=E9=E9 un utilisateur firefox, je lui ai donn=E9 un mot de passe
et acc=E8s =E0 un shell.
Les r=E9pertoires des utilisateurs ne sont accessible qu'=E0 leur
propri=E9taire (d'ailleurs pourquoi ce n'est pas le cas dans les
distribution Linux en g=E9n=E9ral ?).
=C7a a l'air de marcher en ex=E9cutant dans un terminal :
su - firefox [+ saisie du mot de passe]
firefox
Je ne sais pas s'il y a moyen de passer en param=E8tre =E0 su le mot de
passe de l'utilisateur firefox. Donc j'ai essay=E9 avec sudo. J'ai ajout=E9
=E0 la fin de /etc/sudoers :
<utilisateur> alcheringa,localhost=3D(firefox) NOPASSWD: /usr/bin/firefox
Et quand je tape
sudo -u firefox firefox
=E7a ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un
processus firefox est lanc=E9 par l'utilisateur firefox mais la fen=EAtre
n'appara=EEt jamais, parfois il n'y a rien.
Un essai avec Epiphany a donn=E9 quelque chose d'un peu diff=E9rent : la
premi=E8re fois =E7a n'a pas march=E9 (la fen=EAtre d'Epiphany est apparue =
et
il s'est plaint d'un probl=E8me de connexion =E0 /tmp/xxxxxxx-socket-xxxx
[=E7a parlait de dbus aussi], puis la fen=EAtre a disparu). J'ai ensuite
essay=E9 avec "su - firefox" + lancer Epiphany, =E7a a march=E9, et depuis =
la
version avec sudo fonctionne aussi.
Voil=E0, si vous avez un avis. Y a-t-il une diff=E9rence entre le lancement
avec sudo et celui en =E9tant r=E9ellement connect=E9 avec l'utilisateur ?
L'initialisation du shell ? Mais =E7a marche =E9galement avec "su firefox",
sans le tiret, puis lancement de Firefox.
Les avis g=E9n=E9raux sur le principe sont =E9galement les bienvenus.
Pour acc=E9der =E0 quelques r=E9pertoires personnels depuis l'instance de
Firefox lanc=E9e avec un autre utilisateur, je pensais =E0 utiliser
=E9ventuellement des liens durs. Et dans une cage pareil : on peut
laisser acc=E8s =E0 certains r=E9pertoires avec des liens durs. Je ne dis p=
as
de b=EAtise, =E7a ne permet pas de sortir de la cage ?
Le Wed, 28 Apr 2010 08:46:42 +0200 Hugues a écrit :
Bijour,
Ce cher Yliur a posté :
> Bonjour > > Sans me casser les pieds à faire une cage (on verra plus tard), mais > pour éviter que Firefox ait le droit d'accéder à n'importe quoi s 'il > était compromis, je me suis dit que ce serait mieux et assez simple > de le faire exécuter par son propre utilisateur.
Pourquoi pas.
> J'ai créé un utilisateur firefox, je lui ai donné un mot de passe > et accès à un shell.
Jusque là, ok.
> Les répertoires des utilisateurs ne sont accessible qu'à leur > propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les > distribution Linux en général ?).
Je ne comprends pas ce que tu veux dire.. : le propriétaire de qui ?
Un utilisateur n'a le droit d'accéder qu'à son répertoire personnel et pas à celui de son voisin.
> Ça a l'air de marcher en exécutant dans un terminal : > su - firefox [+ saisie du mot de passe] > firefox > > Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de > passe de l'utilisateur firefox.
Non, il faudrait jouer avec PAM, je pense, mais à chaud je ne vois pas comment...
> Donc j'ai essayé avec sudo. J'ai ajouté > à la fin de /etc/sudoers : > <utilisateur> alcheringa,localhost=(firefox) > NOPASSWD: /usr/bin/firefox
C'est une meilleure idée, en effet.
> Et quand je tape > sudo -u firefox firefox > > ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un > processus firefox est lancé par l'utilisateur firefox mais la > fenêtre n'apparaît jamais, parfois il n'y a rien.
Vérifie le comportement des variables d'environnement telles que HOME, il est bien possible qu'elles soient restées aux valeurs de l'utilisateur <user lambda>...
> [...] > Les avis généraux sur le principe sont également les bienvenus.
sudo aura tendance à ne pas mettre à jour toutes les variables d'environnement, typiquement le PATH, HOME, etc.. man sudoers pour avoir plus d'infos..
Alors qu'avec su, tu as la garantie de faire un login complet, avec mise à zéro des différentes variables shell.
Selon moi, l'utilisateur firefox n'a même pas besoin d'avoir un shell dans son /etc/passwd avec sudo, mais c'est à tester..
Je ne voulais pas lui en mettre à l'origine, mais je l'ai fait pour les tests finalement. Effectivement ça marche sans, ce qui est sans doute mieux. Et sans mot de passe non plus (avec un "!" dans la deuxième colonne de /etc/shadow).
> Pour accéder à quelques répertoires personnels depuis l'instance de > Firefox lancée avec un autre utilisateur, je pensais à utiliser > éventuellement des liens durs. Et dans une cage pareil : on peut > laisser accès à certains répertoires avec des liens durs. Je ne d is > pas de bêtise, ça ne permet pas de sortir de la cage ?
Trop de complication nuit à la sécurité : keep it simple, keep it stupid. L'idée du sudo est déjà pas mal à mon goût.
C'est pour qu'en utilisant le logiciel aux droits limités on puisse quand même accéder à certains répertoires. Par exemple : avec un logiciel de messagerie, accéder à la boîte aux lettres depuis le répertoire personnel de l'utilisateur réel et depuis celui de l'utilisateur "fictif".
Le Wed, 28 Apr 2010 08:46:42 +0200
Hugues <hiegel@hugues.fr> a écrit :
Bijour,
Ce cher Yliur <yliur@free.fr> a posté :
> Bonjour
>
> Sans me casser les pieds à faire une cage (on verra plus tard), mais
> pour éviter que Firefox ait le droit d'accéder à n'importe quoi s 'il
> était compromis, je me suis dit que ce serait mieux et assez simple
> de le faire exécuter par son propre utilisateur.
Pourquoi pas.
> J'ai créé un utilisateur firefox, je lui ai donné un mot de passe
> et accès à un shell.
Jusque là, ok.
> Les répertoires des utilisateurs ne sont accessible qu'à leur
> propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les
> distribution Linux en général ?).
Je ne comprends pas ce que tu veux dire.. : le propriétaire de qui ?
Un utilisateur n'a le droit d'accéder qu'à son répertoire personnel et
pas à celui de son voisin.
> Ça a l'air de marcher en exécutant dans un terminal :
> su - firefox [+ saisie du mot de passe]
> firefox
>
> Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de
> passe de l'utilisateur firefox.
Non, il faudrait jouer avec PAM, je pense, mais à chaud je ne vois
pas comment...
> Donc j'ai essayé avec sudo. J'ai ajouté
> à la fin de /etc/sudoers :
> <utilisateur> alcheringa,localhost=(firefox)
> NOPASSWD: /usr/bin/firefox
C'est une meilleure idée, en effet.
> Et quand je tape
> sudo -u firefox firefox
>
> ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un
> processus firefox est lancé par l'utilisateur firefox mais la
> fenêtre n'apparaît jamais, parfois il n'y a rien.
Vérifie le comportement des variables d'environnement telles que
HOME, il est bien possible qu'elles soient restées aux
valeurs de l'utilisateur <user lambda>...
> [...]
> Les avis généraux sur le principe sont également les bienvenus.
sudo aura tendance à ne pas mettre à jour toutes les
variables d'environnement, typiquement le PATH, HOME, etc..
man sudoers pour avoir plus d'infos..
Alors qu'avec su, tu as la garantie de faire un login complet, avec
mise à zéro des différentes variables shell.
Selon moi, l'utilisateur firefox n'a même pas besoin d'avoir un
shell dans son /etc/passwd avec sudo, mais c'est à tester..
Je ne voulais pas lui en mettre à l'origine, mais je l'ai fait pour les
tests finalement. Effectivement ça marche sans, ce qui est sans doute
mieux. Et sans mot de passe non plus (avec un "!" dans la deuxième
colonne de /etc/shadow).
> Pour accéder à quelques répertoires personnels depuis l'instance de
> Firefox lancée avec un autre utilisateur, je pensais à utiliser
> éventuellement des liens durs. Et dans une cage pareil : on peut
> laisser accès à certains répertoires avec des liens durs. Je ne d is
> pas de bêtise, ça ne permet pas de sortir de la cage ?
Trop de complication nuit à la sécurité : keep it simple, keep it
stupid. L'idée du sudo est déjà pas mal à mon goût.
C'est pour qu'en utilisant le logiciel aux droits limités on puisse
quand même accéder à certains répertoires. Par exemple : avec un
logiciel de messagerie, accéder à la boîte aux lettres depuis le
répertoire personnel de l'utilisateur réel et depuis celui de
l'utilisateur "fictif".
Le Wed, 28 Apr 2010 08:46:42 +0200 Hugues a écrit :
Bijour,
Ce cher Yliur a posté :
> Bonjour > > Sans me casser les pieds à faire une cage (on verra plus tard), mais > pour éviter que Firefox ait le droit d'accéder à n'importe quoi s 'il > était compromis, je me suis dit que ce serait mieux et assez simple > de le faire exécuter par son propre utilisateur.
Pourquoi pas.
> J'ai créé un utilisateur firefox, je lui ai donné un mot de passe > et accès à un shell.
Jusque là, ok.
> Les répertoires des utilisateurs ne sont accessible qu'à leur > propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les > distribution Linux en général ?).
Je ne comprends pas ce que tu veux dire.. : le propriétaire de qui ?
Un utilisateur n'a le droit d'accéder qu'à son répertoire personnel et pas à celui de son voisin.
> Ça a l'air de marcher en exécutant dans un terminal : > su - firefox [+ saisie du mot de passe] > firefox > > Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de > passe de l'utilisateur firefox.
Non, il faudrait jouer avec PAM, je pense, mais à chaud je ne vois pas comment...
> Donc j'ai essayé avec sudo. J'ai ajouté > à la fin de /etc/sudoers : > <utilisateur> alcheringa,localhost=(firefox) > NOPASSWD: /usr/bin/firefox
C'est une meilleure idée, en effet.
> Et quand je tape > sudo -u firefox firefox > > ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un > processus firefox est lancé par l'utilisateur firefox mais la > fenêtre n'apparaît jamais, parfois il n'y a rien.
Vérifie le comportement des variables d'environnement telles que HOME, il est bien possible qu'elles soient restées aux valeurs de l'utilisateur <user lambda>...
> [...] > Les avis généraux sur le principe sont également les bienvenus.
sudo aura tendance à ne pas mettre à jour toutes les variables d'environnement, typiquement le PATH, HOME, etc.. man sudoers pour avoir plus d'infos..
Alors qu'avec su, tu as la garantie de faire un login complet, avec mise à zéro des différentes variables shell.
Selon moi, l'utilisateur firefox n'a même pas besoin d'avoir un shell dans son /etc/passwd avec sudo, mais c'est à tester..
Je ne voulais pas lui en mettre à l'origine, mais je l'ai fait pour les tests finalement. Effectivement ça marche sans, ce qui est sans doute mieux. Et sans mot de passe non plus (avec un "!" dans la deuxième colonne de /etc/shadow).
> Pour accéder à quelques répertoires personnels depuis l'instance de > Firefox lancée avec un autre utilisateur, je pensais à utiliser > éventuellement des liens durs. Et dans une cage pareil : on peut > laisser accès à certains répertoires avec des liens durs. Je ne d is > pas de bêtise, ça ne permet pas de sortir de la cage ?
Trop de complication nuit à la sécurité : keep it simple, keep it stupid. L'idée du sudo est déjà pas mal à mon goût.
C'est pour qu'en utilisant le logiciel aux droits limités on puisse quand même accéder à certains répertoires. Par exemple : avec un logiciel de messagerie, accéder à la boîte aux lettres depuis le répertoire personnel de l'utilisateur réel et depuis celui de l'utilisateur "fictif".
Yliur
Le Wed, 28 Apr 2010 14:22:52 +0200 appzer0 a écrit :
Hugues wrote:
>> J'ai créé un utilisateur firefox, je lui ai donné un mot de passe >> et accès à un shell.
Peut-être même que tu peux lui donner un faux shell, à savoir /bin/false (qui doit faire partie de /etc/shells sunr une distro linux standard, ubuntu je ne sais pas)
>> Les répertoires des utilisateurs ne sont accessible qu'à leur >> propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les >> distribution Linux en général ?). > Ça c'est la politique de la distro. Sur Slackware par exemple, les home/user/ sont en 755, fichiers en 644 comme bcp d'autres distro, donc accessibles aux autres (le groupe et aussi les autres) . C'est à toi de décider si tu veux restreindre l'accès ou pas à ces répertoires au seul groupe/propriétaire.
Oui, mais je trouve ça moyen comme politique :) . Pas très sécurisé. Surtout que c'est aussi comme ça dans les distributions grand public (enfin au moins Ubuntu/Mint), et l'utilisateur qui clique sur les boutons pour créer un utilisateur il va sans doute pas penser à faire un "sudo chmod 700" sur le nouveau répertoire.
Le Wed, 28 Apr 2010 14:22:52 +0200
appzer0 <appzer0@freeRemoveThis.frRemoveThis> a écrit :
Hugues wrote:
>> J'ai créé un utilisateur firefox, je lui ai donné un mot de passe
>> et accès à un shell.
Peut-être même que tu peux lui donner un faux shell, à
savoir /bin/false (qui doit faire partie de /etc/shells sunr une
distro linux standard, ubuntu je ne sais pas)
>> Les répertoires des utilisateurs ne sont accessible qu'à leur
>> propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les
>> distribution Linux en général ?).
>
Ça c'est la politique de la distro. Sur Slackware par exemple, les
home/user/ sont en 755, fichiers en 644 comme bcp d'autres distro,
donc accessibles aux autres (le groupe et aussi les autres) . C'est à
toi de décider si tu veux restreindre l'accès ou pas à ces
répertoires au seul groupe/propriétaire.
Oui, mais je trouve ça moyen comme politique :) . Pas très sécurisé.
Surtout que c'est aussi comme ça dans les distributions grand public
(enfin au moins Ubuntu/Mint), et l'utilisateur qui clique sur les
boutons pour créer un utilisateur il va sans doute pas penser à faire
un "sudo chmod 700" sur le nouveau répertoire.
Le Wed, 28 Apr 2010 14:22:52 +0200 appzer0 a écrit :
Hugues wrote:
>> J'ai créé un utilisateur firefox, je lui ai donné un mot de passe >> et accès à un shell.
Peut-être même que tu peux lui donner un faux shell, à savoir /bin/false (qui doit faire partie de /etc/shells sunr une distro linux standard, ubuntu je ne sais pas)
>> Les répertoires des utilisateurs ne sont accessible qu'à leur >> propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les >> distribution Linux en général ?). > Ça c'est la politique de la distro. Sur Slackware par exemple, les home/user/ sont en 755, fichiers en 644 comme bcp d'autres distro, donc accessibles aux autres (le groupe et aussi les autres) . C'est à toi de décider si tu veux restreindre l'accès ou pas à ces répertoires au seul groupe/propriétaire.
Oui, mais je trouve ça moyen comme politique :) . Pas très sécurisé. Surtout que c'est aussi comme ça dans les distributions grand public (enfin au moins Ubuntu/Mint), et l'utilisateur qui clique sur les boutons pour créer un utilisateur il va sans doute pas penser à faire un "sudo chmod 700" sur le nouveau répertoire.
Yliur
Le 28 Apr 2010 08:23:49 GMT Bastien Durel a écrit :
Le Tue, 27 Apr 2010 18:49:28 +0200, Yliur a écrit : > Bonjour > bonjour, [...] > Et quand je tape > sudo -u firefox firefox > Tu peux essayer avec sudo -H pour placer $HOME, voir -i pour simuler le login (comme le "-" de "su - user")
Ça marche mieux avec -H :) . Par contre avec -i il me demande un mot de passe, ça ne m'arrange pas
Par contre, je ne vois pas comment il va parler au serveur X ... mais avec su - non plus. (à moins de transférer le MIT-cookie)
Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une appli graphique depuis un terminal après avoir fait "su -". Qu'est-ce qui pourrait le gêner ?
Le 28 Apr 2010 08:23:49 GMT
Bastien Durel <bastien.durel@data.fr> a écrit :
Le Tue, 27 Apr 2010 18:49:28 +0200, Yliur a écrit :
> Bonjour
>
bonjour,
[...]
> Et quand je tape
> sudo -u firefox firefox
>
Tu peux essayer avec sudo -H pour placer $HOME, voir -i pour simuler
le login (comme le "-" de "su - user")
Ça marche mieux avec -H :) .
Par contre avec -i il me demande un mot de passe, ça ne m'arrange pas
Par contre, je ne vois pas comment il va parler au serveur X ... mais
avec su - non plus. (à moins de transférer le MIT-cookie)
Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une
appli graphique depuis un terminal après avoir fait "su -". Qu'est-ce
qui pourrait le gêner ?
Le 28 Apr 2010 08:23:49 GMT Bastien Durel a écrit :
Le Tue, 27 Apr 2010 18:49:28 +0200, Yliur a écrit : > Bonjour > bonjour, [...] > Et quand je tape > sudo -u firefox firefox > Tu peux essayer avec sudo -H pour placer $HOME, voir -i pour simuler le login (comme le "-" de "su - user")
Ça marche mieux avec -H :) . Par contre avec -i il me demande un mot de passe, ça ne m'arrange pas
Par contre, je ne vois pas comment il va parler au serveur X ... mais avec su - non plus. (à moins de transférer le MIT-cookie)
Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une appli graphique depuis un terminal après avoir fait "su -". Qu'est-ce qui pourrait le gêner ?
Yliur
Le Thu, 29 Apr 2010 10:57:26 +0200 Yannick Patois a écrit :
Le 27.04.2010 18:49, Yliur a écrit : > Et quand je tape > sudo -u firefox firefox
Essaie sux, sinon, tu vas au devant de gros problèmes avec X.
Yannick
Qu'est-ce qui pourrait gêner le serveur X ?
Le Thu, 29 Apr 2010 10:57:26 +0200
Yannick Patois <patois@altespace.org> a écrit :
Le 27.04.2010 18:49, Yliur a écrit :
> Et quand je tape
> sudo -u firefox firefox
Essaie sux, sinon, tu vas au devant de gros problèmes avec X.
Le Thu, 29 Apr 2010 10:57:26 +0200 Yannick Patois a écrit :
Le 27.04.2010 18:49, Yliur a écrit : > Et quand je tape > sudo -u firefox firefox
Essaie sux, sinon, tu vas au devant de gros problèmes avec X.
Yannick
Qu'est-ce qui pourrait gêner le serveur X ?
Yliur
Le Tue, 27 Apr 2010 18:49:28 +0200 Yliur a écrit :
Bonjour
Sans me casser les pieds à faire une cage (on verra plus tard), mais pour éviter que Firefox ait le droit d'accéder à n'importe quoi s'il était compromis, je me suis dit que ce serait mieux et assez simple de le faire exécuter par son propre utilisateur.
J'ai créé un utilisateur firefox, je lui ai donné un mot de passe et accès à un shell.
Les répertoires des utilisateurs ne sont accessible qu'à leur propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les distribution Linux en général ?).
Ça a l'air de marcher en exécutant dans un terminal : su - firefox [+ saisie du mot de passe] firefox
Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de passe de l'utilisateur firefox. Donc j'ai essayé avec sudo. J'ai ajouté à la fin de /etc/sudoers : <utilisateur> alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
Et quand je tape sudo -u firefox firefox
ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un processus firefox est lancé par l'utilisateur firefox mais la fenêtre n'apparaît jamais, parfois il n'y a rien.
Un essai avec Epiphany a donné quelque chose d'un peu différent : la première fois ça n'a pas marché (la fenêtre d'Epiphany est apparu e et il s'est plaint d'un problème de connexion à /tmp/xxxxxxx-socket-xxxx [ça parlait de dbus aussi], puis la fenêtre a disparu). J'ai ensuite essayé avec "su - firefox" + lancer Epiphany, ça a marché, et depuis la version avec sudo fonctionne aussi.
Voilà, si vous avez un avis. Y a-t-il une différence entre le lancement avec sudo et celui en étant réellement connecté avec l'utilisateur ? L'initialisation du shell ? Mais ça marche également avec "su firefox", sans le tiret, puis lancement de Firefox.
Les avis généraux sur le principe sont également les bienvenus.
Pour accéder à quelques répertoires personnels depuis l'instance de Firefox lancée avec un autre utilisateur, je pensais à utiliser éventuellement des liens durs. Et dans une cage pareil : on peut laisser accès à certains répertoires avec des liens durs. Je ne dis pas de bêtise, ça ne permet pas de sortir de la cage ?
Merci
Voilà où j'en suis :
- J'ai créé un utilisateur sans mot de passe, sans shell et qui a des droits sur son répertoire personnel et pas sur le mien.
- J'ai modifié mon fichier sudoers et ça ressemble à ça : moi alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
(j'ai essayé d'ajouter NOEXEC:, mais Firefox fait la gueule rien que pour accéder à sa configuration, il se sert sans de programmes externes pour ça...)
- Je lance Firefox (depuis un menu graphique) avec la commande sudo -Hu firefox firefox (le "-u firefox" pour choisir l'utilisateur, -H pour utiliser son répertoire personnel plutôt que le mien [utiliser sa variable $HOME], le "firefox" final pour lancer le programme)
A première vue ça marche, à voir sur plus longtemps :) . Et ne pas oublier de sauvegarder le répertoire de ce nouvel utilisateur, il y a mes données dedans.
Si ça fonctionne je crois que je vais m'attaquer à d'autres programmes. C'est plus léger que les cages (quoique je crois qu'il y a une méthode de création/gestion de cages assez simple dans Archlinux, à essayer).
Le Tue, 27 Apr 2010 18:49:28 +0200
Yliur <yliur@free.fr> a écrit :
Bonjour
Sans me casser les pieds à faire une cage (on verra plus tard), mais
pour éviter que Firefox ait le droit d'accéder à n'importe quoi s'il
était compromis, je me suis dit que ce serait mieux et assez simple de
le faire exécuter par son propre utilisateur.
J'ai créé un utilisateur firefox, je lui ai donné un mot de passe
et accès à un shell.
Les répertoires des utilisateurs ne sont accessible qu'à leur
propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les
distribution Linux en général ?).
Ça a l'air de marcher en exécutant dans un terminal :
su - firefox [+ saisie du mot de passe]
firefox
Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de
passe de l'utilisateur firefox. Donc j'ai essayé avec sudo. J'ai
ajouté à la fin de /etc/sudoers :
<utilisateur> alcheringa,localhost=(firefox)
NOPASSWD: /usr/bin/firefox
Et quand je tape
sudo -u firefox firefox
ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un
processus firefox est lancé par l'utilisateur firefox mais la fenêtre
n'apparaît jamais, parfois il n'y a rien.
Un essai avec Epiphany a donné quelque chose d'un peu différent : la
première fois ça n'a pas marché (la fenêtre d'Epiphany est apparu e et
il s'est plaint d'un problème de connexion à /tmp/xxxxxxx-socket-xxxx
[ça parlait de dbus aussi], puis la fenêtre a disparu). J'ai ensuite
essayé avec "su - firefox" + lancer Epiphany, ça a marché, et depuis
la version avec sudo fonctionne aussi.
Voilà, si vous avez un avis. Y a-t-il une différence entre le
lancement avec sudo et celui en étant réellement connecté avec
l'utilisateur ? L'initialisation du shell ? Mais ça marche également
avec "su firefox", sans le tiret, puis lancement de Firefox.
Les avis généraux sur le principe sont également les bienvenus.
Pour accéder à quelques répertoires personnels depuis l'instance de
Firefox lancée avec un autre utilisateur, je pensais à utiliser
éventuellement des liens durs. Et dans une cage pareil : on peut
laisser accès à certains répertoires avec des liens durs. Je ne dis
pas de bêtise, ça ne permet pas de sortir de la cage ?
Merci
Voilà où j'en suis :
- J'ai créé un utilisateur sans mot de passe, sans shell et qui a des
droits sur son répertoire personnel et pas sur le mien.
- J'ai modifié mon fichier sudoers et ça ressemble à ça :
moi alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
(j'ai essayé d'ajouter NOEXEC:, mais Firefox fait la gueule rien que
pour accéder à sa configuration, il se sert sans de programmes externes
pour ça...)
- Je lance Firefox (depuis un menu graphique) avec la commande
sudo -Hu firefox firefox
(le "-u firefox" pour choisir l'utilisateur, -H pour utiliser son
répertoire personnel plutôt que le mien [utiliser sa variable $HOME], le
"firefox" final pour lancer le programme)
A première vue ça marche, à voir sur plus longtemps :) .
Et ne pas oublier de sauvegarder le répertoire de ce nouvel
utilisateur, il y a mes données dedans.
Si ça fonctionne je crois que je vais m'attaquer à d'autres programmes.
C'est plus léger que les cages (quoique je crois qu'il y a une méthode
de création/gestion de cages assez simple dans Archlinux, à essayer).
Le Tue, 27 Apr 2010 18:49:28 +0200 Yliur a écrit :
Bonjour
Sans me casser les pieds à faire une cage (on verra plus tard), mais pour éviter que Firefox ait le droit d'accéder à n'importe quoi s'il était compromis, je me suis dit que ce serait mieux et assez simple de le faire exécuter par son propre utilisateur.
J'ai créé un utilisateur firefox, je lui ai donné un mot de passe et accès à un shell.
Les répertoires des utilisateurs ne sont accessible qu'à leur propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les distribution Linux en général ?).
Ça a l'air de marcher en exécutant dans un terminal : su - firefox [+ saisie du mot de passe] firefox
Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de passe de l'utilisateur firefox. Donc j'ai essayé avec sudo. J'ai ajouté à la fin de /etc/sudoers : <utilisateur> alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
Et quand je tape sudo -u firefox firefox
ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un processus firefox est lancé par l'utilisateur firefox mais la fenêtre n'apparaît jamais, parfois il n'y a rien.
Un essai avec Epiphany a donné quelque chose d'un peu différent : la première fois ça n'a pas marché (la fenêtre d'Epiphany est apparu e et il s'est plaint d'un problème de connexion à /tmp/xxxxxxx-socket-xxxx [ça parlait de dbus aussi], puis la fenêtre a disparu). J'ai ensuite essayé avec "su - firefox" + lancer Epiphany, ça a marché, et depuis la version avec sudo fonctionne aussi.
Voilà, si vous avez un avis. Y a-t-il une différence entre le lancement avec sudo et celui en étant réellement connecté avec l'utilisateur ? L'initialisation du shell ? Mais ça marche également avec "su firefox", sans le tiret, puis lancement de Firefox.
Les avis généraux sur le principe sont également les bienvenus.
Pour accéder à quelques répertoires personnels depuis l'instance de Firefox lancée avec un autre utilisateur, je pensais à utiliser éventuellement des liens durs. Et dans une cage pareil : on peut laisser accès à certains répertoires avec des liens durs. Je ne dis pas de bêtise, ça ne permet pas de sortir de la cage ?
Merci
Voilà où j'en suis :
- J'ai créé un utilisateur sans mot de passe, sans shell et qui a des droits sur son répertoire personnel et pas sur le mien.
- J'ai modifié mon fichier sudoers et ça ressemble à ça : moi alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
(j'ai essayé d'ajouter NOEXEC:, mais Firefox fait la gueule rien que pour accéder à sa configuration, il se sert sans de programmes externes pour ça...)
- Je lance Firefox (depuis un menu graphique) avec la commande sudo -Hu firefox firefox (le "-u firefox" pour choisir l'utilisateur, -H pour utiliser son répertoire personnel plutôt que le mien [utiliser sa variable $HOME], le "firefox" final pour lancer le programme)
A première vue ça marche, à voir sur plus longtemps :) . Et ne pas oublier de sauvegarder le répertoire de ce nouvel utilisateur, il y a mes données dedans.
Si ça fonctionne je crois que je vais m'attaquer à d'autres programmes. C'est plus léger que les cages (quoique je crois qu'il y a une méthode de création/gestion de cages assez simple dans Archlinux, à essayer).
Bastien Durel
Le Thu, 29 Apr 2010 16:58:46 +0200, Yliur a écrit :
Par contre, je ne vois pas comment il va parler au serveur X ... mais avec su - non plus. (à moins de transférer le MIT-cookie)
Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une appli graphique depuis un terminal après avoir fait "su -". Qu'est-ce qui pourrait le gêner ?
:~/$ su - upgrade Mot de passe : $ xlogo Error: Can't open display: $ export DISPLAY=:0.0 $ xlogo No protocol specified Error: Can't open display: 0:0
le serveur X n'est pas sensé répondre à un autre utilisateur que celui qui est loggué. Sinon, c'est pas sûr, un gas qui se loggue sur la machine en SSH pourrait prendre le contrôle de la souris, du clavier, faire des copies d'écran ... un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et hop ! on lance xlock :D
Le Thu, 29 Apr 2010 16:58:46 +0200, Yliur a écrit :
Par contre, je ne vois pas comment il va parler au serveur X ... mais
avec su - non plus. (à moins de transférer le MIT-cookie)
Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une appli
graphique depuis un terminal après avoir fait "su -". Qu'est-ce qui
pourrait le gêner ?
bastien@data-dev3:~/$ su - upgrade
Mot de passe :
$ xlogo
Error: Can't open display:
$ export DISPLAY=:0.0
$ xlogo
No protocol specified
Error: Can't open display: 0:0
le serveur X n'est pas sensé répondre à un autre utilisateur que celui
qui est loggué. Sinon, c'est pas sûr, un gas qui se loggue sur la machine
en SSH pourrait prendre le contrôle de la souris, du clavier, faire des
copies d'écran ...
un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et
hop ! on lance xlock :D
Le Thu, 29 Apr 2010 16:58:46 +0200, Yliur a écrit :
Par contre, je ne vois pas comment il va parler au serveur X ... mais avec su - non plus. (à moins de transférer le MIT-cookie)
Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une appli graphique depuis un terminal après avoir fait "su -". Qu'est-ce qui pourrait le gêner ?
:~/$ su - upgrade Mot de passe : $ xlogo Error: Can't open display: $ export DISPLAY=:0.0 $ xlogo No protocol specified Error: Can't open display: 0:0
le serveur X n'est pas sensé répondre à un autre utilisateur que celui qui est loggué. Sinon, c'est pas sûr, un gas qui se loggue sur la machine en SSH pourrait prendre le contrôle de la souris, du clavier, faire des copies d'écran ... un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et hop ! on lance xlock :D
Christian
appzer0 a écrit:
Ça c'est la politique de la distro. Sur Slackware par exemple, les home/user/ sont en 755, fichiers en 644 comme bcp d'autres distro, donc accessibles aux autres (le groupe et aussi les autres) .
ils ne sont pas accessibles dans la mesure où les répertoires /home/*/ sont en 711
-- Christian
appzer0 a écrit:
Ça c'est la politique de la distro. Sur Slackware par exemple, les
home/user/ sont en 755, fichiers en 644 comme bcp d'autres distro,
donc accessibles aux autres (le groupe et aussi les autres) .
ils ne sont pas accessibles dans la mesure où les répertoires /home/*/
sont en 711
Ça c'est la politique de la distro. Sur Slackware par exemple, les home/user/ sont en 755, fichiers en 644 comme bcp d'autres distro, donc accessibles aux autres (le groupe et aussi les autres) .
ils ne sont pas accessibles dans la mesure où les répertoires /home/*/ sont en 711
-- Christian
Yliur
Le 29 Apr 2010 15:31:04 GMT Bastien Durel a écrit :
Le Thu, 29 Apr 2010 16:58:46 +0200, Yliur a écrit : >> Par contre, je ne vois pas comment il va parler au serveur X ... >> mais avec su - non plus. (à moins de transférer le MIT-cookie) > > Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une > appli graphique depuis un terminal après avoir fait "su -". > Qu'est-ce qui pourrait le gêner ? :~/$ su - upgrade Mot de passe : $ xlogo Error: Can't open display: $ export DISPLAY=:0.0 $ xlogo No protocol specified Error: Can't open display: 0:0
le serveur X n'est pas sensé répondre à un autre utilisateur que celui qui est loggué. Sinon, c'est pas sûr, un gas qui se loggue sur la machine en SSH pourrait prendre le contrôle de la souris, du clavier, faire des copies d'écran ...
Ok.
En pratique ici ça marche, je ne sais pas si c'est la configuration par défaut de Xorg, je n'y ai pas touché depuis l'installation.
un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et hop ! on lance xlock :D
Je ne sais pas ce que fait xhost, mais à l'Université on utilisait des terminaux (physiques), et on pouvait lancer des trucs sur d'autres terminaux en modifiant la variable DISPLAY-je-sais-trop-quoi.
Le 29 Apr 2010 15:31:04 GMT
Bastien Durel <bastien.durel@data.fr> a écrit :
Le Thu, 29 Apr 2010 16:58:46 +0200, Yliur a écrit :
>> Par contre, je ne vois pas comment il va parler au serveur X ...
>> mais avec su - non plus. (à moins de transférer le MIT-cookie)
>
> Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une
> appli graphique depuis un terminal après avoir fait "su -".
> Qu'est-ce qui pourrait le gêner ?
bastien@data-dev3:~/$ su - upgrade
Mot de passe :
$ xlogo
Error: Can't open display:
$ export DISPLAY=:0.0
$ xlogo
No protocol specified
Error: Can't open display: 0:0
le serveur X n'est pas sensé répondre à un autre utilisateur que
celui qui est loggué. Sinon, c'est pas sûr, un gas qui se loggue sur
la machine en SSH pourrait prendre le contrôle de la souris, du
clavier, faire des copies d'écran ...
Ok.
En pratique ici ça marche, je ne sais pas si c'est la configuration
par défaut de Xorg, je n'y ai pas touché depuis l'installation.
un grand jeu à l'école c'était le "xhost +" dans le dos des voisins,
et hop ! on lance xlock :D
Je ne sais pas ce que fait xhost, mais à l'Université on utilisait des
terminaux (physiques), et on pouvait lancer des trucs sur d'autres
terminaux en modifiant la variable DISPLAY-je-sais-trop-quoi.
Le 29 Apr 2010 15:31:04 GMT Bastien Durel a écrit :
Le Thu, 29 Apr 2010 16:58:46 +0200, Yliur a écrit : >> Par contre, je ne vois pas comment il va parler au serveur X ... >> mais avec su - non plus. (à moins de transférer le MIT-cookie) > > Je ne comprends pas. Je n'ai jamais eu de problème pour lancer une > appli graphique depuis un terminal après avoir fait "su -". > Qu'est-ce qui pourrait le gêner ? :~/$ su - upgrade Mot de passe : $ xlogo Error: Can't open display: $ export DISPLAY=:0.0 $ xlogo No protocol specified Error: Can't open display: 0:0
le serveur X n'est pas sensé répondre à un autre utilisateur que celui qui est loggué. Sinon, c'est pas sûr, un gas qui se loggue sur la machine en SSH pourrait prendre le contrôle de la souris, du clavier, faire des copies d'écran ...
Ok.
En pratique ici ça marche, je ne sais pas si c'est la configuration par défaut de Xorg, je n'y ai pas touché depuis l'installation.
un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et hop ! on lance xlock :D
Je ne sais pas ce que fait xhost, mais à l'Université on utilisait des terminaux (physiques), et on pouvait lancer des trucs sur d'autres terminaux en modifiant la variable DISPLAY-je-sais-trop-quoi.
Bastien Durel
Le Thu, 29 Apr 2010 17:40:20 +0200, Yliur a écrit :
En pratique ici ça marche, je ne sais pas si c'est la configuration par défaut de Xorg, je n'y ai pas touché depuis l'installation.
C'est étrange. (et pas très sécure) Chez moi il refuse tout par défaut.
un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et hop ! on lance xlock :D
Je ne sais pas ce que fait xhost,
ça détermine de qui le serveur X accepte les ordres. xhost + ça veut dire de tout le monde.
mais à l'Université on utilisait des terminaux (physiques), et on pouvait lancer des trucs sur d'autres terminaux en modifiant la variable DISPLAY-je-sais-trop-quoi.
DISPLAY tout court.
Le Thu, 29 Apr 2010 17:40:20 +0200, Yliur a écrit :
En pratique ici ça marche, je ne sais pas si c'est la configuration par
défaut de Xorg, je n'y ai pas touché depuis l'installation.
C'est étrange. (et pas très sécure) Chez moi il refuse tout par défaut.
un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et
hop ! on lance xlock :D
Je ne sais pas ce que fait xhost,
ça détermine de qui le serveur X accepte les ordres. xhost + ça veut dire
de tout le monde.
mais à l'Université on utilisait des
terminaux (physiques), et on pouvait lancer des trucs sur d'autres
terminaux en modifiant la variable DISPLAY-je-sais-trop-quoi.
Le Thu, 29 Apr 2010 17:40:20 +0200, Yliur a écrit :
En pratique ici ça marche, je ne sais pas si c'est la configuration par défaut de Xorg, je n'y ai pas touché depuis l'installation.
C'est étrange. (et pas très sécure) Chez moi il refuse tout par défaut.
un grand jeu à l'école c'était le "xhost +" dans le dos des voisins, et hop ! on lance xlock :D
Je ne sais pas ce que fait xhost,
ça détermine de qui le serveur X accepte les ordres. xhost + ça veut dire de tout le monde.
mais à l'Université on utilisait des terminaux (physiques), et on pouvait lancer des trucs sur d'autres terminaux en modifiant la variable DISPLAY-je-sais-trop-quoi.
DISPLAY tout court.
Yliur
Le Thu, 29 Apr 2010 17:19:27 +0200 Yliur a écrit :
Le Tue, 27 Apr 2010 18:49:28 +0200 Yliur a écrit :
> Bonjour > > Sans me casser les pieds à faire une cage (on verra plus tard), mais > pour éviter que Firefox ait le droit d'accéder à n'importe quoi s 'il > était compromis, je me suis dit que ce serait mieux et assez simple > de le faire exécuter par son propre utilisateur. > > J'ai créé un utilisateur firefox, je lui ai donné un mot de passe > et accès à un shell. > > Les répertoires des utilisateurs ne sont accessible qu'à leur > propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les > distribution Linux en général ?). > > Ça a l'air de marcher en exécutant dans un terminal : > su - firefox [+ saisie du mot de passe] > firefox > > Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de > passe de l'utilisateur firefox. Donc j'ai essayé avec sudo. J'ai > ajouté à la fin de /etc/sudoers : > <utilisateur> alcheringa,localhost=(firefox) > NOPASSWD: /usr/bin/firefox > > Et quand je tape > sudo -u firefox firefox > > ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un > processus firefox est lancé par l'utilisateur firefox mais la > fenêtre n'apparaît jamais, parfois il n'y a rien. > > Un essai avec Epiphany a donné quelque chose d'un peu différent : la > première fois ça n'a pas marché (la fenêtre d'Epiphany est appa rue > et il s'est plaint d'un problème de connexion > à /tmp/xxxxxxx-socket-xxxx [ça parlait de dbus aussi], puis la > fenêtre a disparu). J'ai ensuite essayé avec "su - firefox" + > lancer Epiphany, ça a marché, et depuis la version avec sudo > fonctionne aussi. > > Voilà, si vous avez un avis. Y a-t-il une différence entre le > lancement avec sudo et celui en étant réellement connecté avec > l'utilisateur ? L'initialisation du shell ? Mais ça marche également > avec "su firefox", sans le tiret, puis lancement de Firefox. > > Les avis généraux sur le principe sont également les bienvenus. > > Pour accéder à quelques répertoires personnels depuis l'instance de > Firefox lancée avec un autre utilisateur, je pensais à utiliser > éventuellement des liens durs. Et dans une cage pareil : on peut > laisser accès à certains répertoires avec des liens durs. Je ne d is > pas de bêtise, ça ne permet pas de sortir de la cage ? > > Merci >
Voilà où j'en suis :
- J'ai créé un utilisateur sans mot de passe, sans shell et qui a des droits sur son répertoire personnel et pas sur le mien.
- J'ai modifié mon fichier sudoers et ça ressemble à ça : moi alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
(j'ai essayé d'ajouter NOEXEC:, mais Firefox fait la gueule rien que pour accéder à sa configuration, il se sert sans de programmes externes pour ça...)
- Je lance Firefox (depuis un menu graphique) avec la commande sudo -Hu firefox firefox (le "-u firefox" pour choisir l'utilisateur, -H pour utiliser son répertoire personnel plutôt que le mien [utiliser sa variable $HOME], le "firefox" final pour lancer le programme)
A première vue ça marche, à voir sur plus longtemps :) . Et ne pas oublier de sauvegarder le répertoire de ce nouvel utilisateur, il y a mes données dedans.
Si ça fonctionne je crois que je vais m'attaquer à d'autres programmes. C'est plus léger que les cages (quoique je crois qu'il y a une méthode de création/gestion de cages assez simple dans Archlinux, à essayer).
Un petit oubli : pour des raisons pratiques, j'ai donné le répertoire /home/firefox au groupe auquel j'appartiens et modifié les droits du groupe sur le répertoire, pour pouvoir lire et écrire dedans.
Le Thu, 29 Apr 2010 17:19:27 +0200
Yliur <yliur@free.fr> a écrit :
Le Tue, 27 Apr 2010 18:49:28 +0200
Yliur <yliur@free.fr> a écrit :
> Bonjour
>
> Sans me casser les pieds à faire une cage (on verra plus tard), mais
> pour éviter que Firefox ait le droit d'accéder à n'importe quoi s 'il
> était compromis, je me suis dit que ce serait mieux et assez simple
> de le faire exécuter par son propre utilisateur.
>
> J'ai créé un utilisateur firefox, je lui ai donné un mot de passe
> et accès à un shell.
>
> Les répertoires des utilisateurs ne sont accessible qu'à leur
> propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les
> distribution Linux en général ?).
>
> Ça a l'air de marcher en exécutant dans un terminal :
> su - firefox [+ saisie du mot de passe]
> firefox
>
> Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de
> passe de l'utilisateur firefox. Donc j'ai essayé avec sudo. J'ai
> ajouté à la fin de /etc/sudoers :
> <utilisateur> alcheringa,localhost=(firefox)
> NOPASSWD: /usr/bin/firefox
>
> Et quand je tape
> sudo -u firefox firefox
>
> ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un
> processus firefox est lancé par l'utilisateur firefox mais la
> fenêtre n'apparaît jamais, parfois il n'y a rien.
>
> Un essai avec Epiphany a donné quelque chose d'un peu différent : la
> première fois ça n'a pas marché (la fenêtre d'Epiphany est appa rue
> et il s'est plaint d'un problème de connexion
> à /tmp/xxxxxxx-socket-xxxx [ça parlait de dbus aussi], puis la
> fenêtre a disparu). J'ai ensuite essayé avec "su - firefox" +
> lancer Epiphany, ça a marché, et depuis la version avec sudo
> fonctionne aussi.
>
> Voilà, si vous avez un avis. Y a-t-il une différence entre le
> lancement avec sudo et celui en étant réellement connecté avec
> l'utilisateur ? L'initialisation du shell ? Mais ça marche également
> avec "su firefox", sans le tiret, puis lancement de Firefox.
>
> Les avis généraux sur le principe sont également les bienvenus.
>
> Pour accéder à quelques répertoires personnels depuis l'instance de
> Firefox lancée avec un autre utilisateur, je pensais à utiliser
> éventuellement des liens durs. Et dans une cage pareil : on peut
> laisser accès à certains répertoires avec des liens durs. Je ne d is
> pas de bêtise, ça ne permet pas de sortir de la cage ?
>
> Merci
>
Voilà où j'en suis :
- J'ai créé un utilisateur sans mot de passe, sans shell et qui a des
droits sur son répertoire personnel et pas sur le mien.
- J'ai modifié mon fichier sudoers et ça ressemble à ça :
moi alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
(j'ai essayé d'ajouter NOEXEC:, mais Firefox fait la gueule rien que
pour accéder à sa configuration, il se sert sans de programmes
externes pour ça...)
- Je lance Firefox (depuis un menu graphique) avec la commande
sudo -Hu firefox firefox
(le "-u firefox" pour choisir l'utilisateur, -H pour utiliser son
répertoire personnel plutôt que le mien [utiliser sa variable $HOME],
le "firefox" final pour lancer le programme)
A première vue ça marche, à voir sur plus longtemps :) .
Et ne pas oublier de sauvegarder le répertoire de ce nouvel
utilisateur, il y a mes données dedans.
Si ça fonctionne je crois que je vais m'attaquer à d'autres
programmes. C'est plus léger que les cages (quoique je crois qu'il y
a une méthode de création/gestion de cages assez simple dans
Archlinux, à essayer).
Un petit oubli : pour des raisons pratiques, j'ai donné le
répertoire /home/firefox au groupe auquel j'appartiens et modifié les
droits du groupe sur le répertoire, pour pouvoir lire et écrire dedans.
Le Thu, 29 Apr 2010 17:19:27 +0200 Yliur a écrit :
Le Tue, 27 Apr 2010 18:49:28 +0200 Yliur a écrit :
> Bonjour > > Sans me casser les pieds à faire une cage (on verra plus tard), mais > pour éviter que Firefox ait le droit d'accéder à n'importe quoi s 'il > était compromis, je me suis dit que ce serait mieux et assez simple > de le faire exécuter par son propre utilisateur. > > J'ai créé un utilisateur firefox, je lui ai donné un mot de passe > et accès à un shell. > > Les répertoires des utilisateurs ne sont accessible qu'à leur > propriétaire (d'ailleurs pourquoi ce n'est pas le cas dans les > distribution Linux en général ?). > > Ça a l'air de marcher en exécutant dans un terminal : > su - firefox [+ saisie du mot de passe] > firefox > > Je ne sais pas s'il y a moyen de passer en paramètre à su le mot de > passe de l'utilisateur firefox. Donc j'ai essayé avec sudo. J'ai > ajouté à la fin de /etc/sudoers : > <utilisateur> alcheringa,localhost=(firefox) > NOPASSWD: /usr/bin/firefox > > Et quand je tape > sudo -u firefox firefox > > ça ne fonctionne pas. Il n'y a pas de message d'erreur, parfois un > processus firefox est lancé par l'utilisateur firefox mais la > fenêtre n'apparaît jamais, parfois il n'y a rien. > > Un essai avec Epiphany a donné quelque chose d'un peu différent : la > première fois ça n'a pas marché (la fenêtre d'Epiphany est appa rue > et il s'est plaint d'un problème de connexion > à /tmp/xxxxxxx-socket-xxxx [ça parlait de dbus aussi], puis la > fenêtre a disparu). J'ai ensuite essayé avec "su - firefox" + > lancer Epiphany, ça a marché, et depuis la version avec sudo > fonctionne aussi. > > Voilà, si vous avez un avis. Y a-t-il une différence entre le > lancement avec sudo et celui en étant réellement connecté avec > l'utilisateur ? L'initialisation du shell ? Mais ça marche également > avec "su firefox", sans le tiret, puis lancement de Firefox. > > Les avis généraux sur le principe sont également les bienvenus. > > Pour accéder à quelques répertoires personnels depuis l'instance de > Firefox lancée avec un autre utilisateur, je pensais à utiliser > éventuellement des liens durs. Et dans une cage pareil : on peut > laisser accès à certains répertoires avec des liens durs. Je ne d is > pas de bêtise, ça ne permet pas de sortir de la cage ? > > Merci >
Voilà où j'en suis :
- J'ai créé un utilisateur sans mot de passe, sans shell et qui a des droits sur son répertoire personnel et pas sur le mien.
- J'ai modifié mon fichier sudoers et ça ressemble à ça : moi alcheringa,localhost=(firefox) NOPASSWD: /usr/bin/firefox
(j'ai essayé d'ajouter NOEXEC:, mais Firefox fait la gueule rien que pour accéder à sa configuration, il se sert sans de programmes externes pour ça...)
- Je lance Firefox (depuis un menu graphique) avec la commande sudo -Hu firefox firefox (le "-u firefox" pour choisir l'utilisateur, -H pour utiliser son répertoire personnel plutôt que le mien [utiliser sa variable $HOME], le "firefox" final pour lancer le programme)
A première vue ça marche, à voir sur plus longtemps :) . Et ne pas oublier de sauvegarder le répertoire de ce nouvel utilisateur, il y a mes données dedans.
Si ça fonctionne je crois que je vais m'attaquer à d'autres programmes. C'est plus léger que les cages (quoique je crois qu'il y a une méthode de création/gestion de cages assez simple dans Archlinux, à essayer).
Un petit oubli : pour des raisons pratiques, j'ai donné le répertoire /home/firefox au groupe auquel j'appartiens et modifié les droits du groupe sur le répertoire, pour pouvoir lire et écrire dedans.
