Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Limiter les accès à la racine

NicolasDa

Bonjour à tous,

Je me trouve face à un problème sans doute bête mais je ne parviens pas à le résoudre.
Je dispose de mon système Ubuntu qui fonctionne correctement.

Lorsque que je crée un nouvel utilisateur pour "jouer", je constate que ce dernier peut se balader sur
tout le système et aller dans les HOME des autres utilisateurs. Il n'a pas le droit d'écriture mais bien de lecture et exécution. Cela me pose problème car si il ne sait pas supprimer et créer des fichiers, il pourrait tout de même lire des fichiers confidentiels...

Pareil pour la racine ou cet utilisateur peut s'y rendre et se promener dans le système!
Dois-je changer donc les droits de la racine et de tout ce qu'elle contient pour donner les accès qu'à son propriétaire et son groupe, tout en bloquant les "autres", du genre chmod -R 770 /
et redonner les droits RWX pour son HOME?

J'ai testé et je ne sais plus faire de sudo! Logique me direz-vous mais que dois-je laisser absolument en lecture pour cet utilisateur afin de limiter aux maximum ces accès?

Je vous remercie grandement pour votre aide.
Nicolas

PS: dernière petite question, pourquoi cet utilisateur de test peux faire un ping par exemple alors qu'il n'est pas dans le groupe %admin du fichier /etc/sudoers? J'aimerais vraiment bien pouvoir créer des utilisateurs qui n'ont accès qu'à leur HOME et qui puissent lancer uniquement les commandes que je défini dans le fichier sudoers.

Encore merci pour votre aide!

NicolasDa

Personne n'a jamais rencontré ce genre de problème?

eric63

salut
c'est le fonctionnement par défaut d' ubuntu.
Mais ça peut être modifié.
et quelques explications là

http://forum.kubuntu-fr.org/viewtopic.php?id=263077

Hoper

Les permissions par défaut ne posent pas de problèmes. Qu'entend tu par "il pourrait lire des fichiers confidentiels". Quels fichiers confidentiels !? Regarde : /etc/shadow est un fichier confidentiel, et bien je t'assure que par defaut il ne pourra jamais afficher son contenu.

Si tu parle de TES données confidentiels, (et pas des fichiers systèmes donc) alors la c'est différent. A toi de modifier les droits sur TON répertoire home, ou sur le fichier à protéger pour que seul toi puisse y avoir accès.

Si tu veux absolument empêcher une personne de se balader alors il faut "chrooter" son home. Mais ca peut vite devenir assez compliqué à gérer, alors que ca ne sert franchement pas à grand chose.

Enfin si tu as vraiment fait un chmod -R sur /, tu peux commencer par ré-installer ton système vu que tu l'a complètement détruit. (il sera en effet très difficile de retrouver les droits exacts, y compris spéciaux, qui étaient attachés à de nombreux fichiers systèmes primordiaux.

NicolasDa

Merci beaucoup pour ton aide!

Cela répond déjà en gros à ma question. Penses-tu qu'après une installation d'ubuntu, il faut passer sur chaque dossier de la racine (ex: /bin) pour enlever les droits en lecture et écriture pour les "autres"? soit, 750 ?

Cela permet déjà d'éviter que les utilisateurs liste le contenu de la racine mais cela ne les empêche pas de lancer des commandes (ex: /bin/ping) étant donné qu'ils ont le droit d'exécution.
Si je change les droits en 750, j'ai peur de tout leur bloquer et que leur compte ne fonctionne pas correctement... Bon OK, il ne sauront plus faire de ping, mais le système pourra-t-il fonctionner correctement en mettant partout 750 de manière récursive? (je pense que oui mais j'aimerais avoir la certitude)

J'ai essayé de manière récursive mais cela pose problème. Des fichiers seraient-ils verrouillés par le système?

Encore merci pour votre retour.

NicolasDa

Hoper a écritLes permissions par défaut ne posent pas de problèmes. Qu'entend tu par "il pourrait lire des fichiers confidentiels". Quels fichiers confidentiels !? Regarde : /etc/shadow est un fichier confidentiel, et bien je t'assure que par defaut il ne pourra jamais afficher son contenu.

Effectivement, mais quand je dis confidentiel, les fichiers de config le sont pour moi aussi (/etc/group par exemple).

Hoper a écritSi tu parle de TES données confidentiels, (et pas des fichiers systèmes donc) alors la c'est différent. A toi de modifier les droits sur TON répertoire home, ou sur le fichier à protéger pour que seul toi puisse y avoir accès.

OK, j'ai compris la marche à suivre en changeant manuellement les droits ou en modifiant le fichier permettant de créer les users

Hoper a écritSi tu veux absolument empêcher une personne de se balader alors il faut "chrooter" son home. Mais ca peut vite devenir assez compliqué à gérer, alors que ca ne sert franchement pas à grand chose.

Tout à fait d'accord avec toi

Hoper a écritEnfin si tu as vraiment fait un chmod -R sur /, tu peux commencer par ré-installer ton système vu que tu l'a complètement détruit. (il sera en effet très difficile de retrouver les droits exacts, y compris spéciaux, qui étaient attachés à de nombreux fichiers systèmes primordiaux.

Vive la virtualisation ici pour revenir en arrière ;-)

Merci pour tes remarques judicieuses en tout cas!

Henry de Monfreid

Je te conseille de ne pas toucher aux permissions de la racine de ton système, tu pourrais le destabiliser.

Pour ton problème, il suffit de modifier les permissions des repertoires home des utilisateurs.

Pas /home mais plutot /home/user.

seb0uil

NicolasDa a écritLorsque que je crée un nouvel utilisateur pour "jouer", je constate que ce dernier peut se balader sur
tout le système et aller dans les HOME des autres utilisateurs. Il n'a pas le droit d'écriture mais bien de lecture et exécution. Cela me pose problème car si il ne sait pas supprimer et créer des fichiers, il pourrait tout de même lire des fichiers confidentiels...

Pour pouvoir se connecter, utiliser des commandes etc.. un utilisateur doit avoir accès à pas mal de répertoire système. C'est normal.
En revanche, si tu veux empêcher qu'un utilisateur n'accède à ton repertoire perso, il faut changer les droits de ce répertoire seulement (chmod o-rwx ~)

Hoper a écritSi tu veux absolument empêcher une personne de se balader alors il faut "chrooter" son home. Mais ca peut vite devenir assez compliqué à gérer, alors que ca ne sert franchement pas à grand chose.

:/ 'chrooter' ca ne sert pas à cà ...

Cela répond déjà en gros à ma question. Penses-tu qu'après une installation d'ubuntu, il faut passer sur chaque dossier de la racine (ex: /bin) pour enlever les droits en lecture et écriture pour les "autres"? soit, 750 ?

Cela permet déjà d'éviter que les utilisateurs liste le contenu de la racine mais cela ne les empêche pas de lancer des commandes (ex: /bin/ping) étant donné qu'ils ont le droit d'exécution.
Si je change les droits en 750, j'ai peur de tout leur bloquer et que leur compte ne fonctionne pas correctement... Bon OK, il ne sauront plus faire de ping, mais le système pourra-t-il fonctionner correctement en mettant partout 750 de manière récursive? (je pense que oui mais j'aimerais avoir la certitude)

J'ai essayé de manière récursive mais cela pose problème. Des fichiers seraient-ils verrouillés par le système?

pour ce qui est de changer les droits sur /bin par exemple, si l'utilisateur ne peut pas lister le répertoire, il ne peut pas lancer de commande qui s'y trouve. Et puis en quoi est ce génant d'avoir accès (en lecture/execution) à /bin

Pour ce qui est des fichiers avec des droits spéciaux, il est existe. Par exemple, le fichier sudoers doit avoir les droits 440 pour que sudo s'execute.

NicolasDa

seb0uil a écritpour ce qui est de changer les droits sur /bin par exemple, si l'utilisateur ne peut pas lister le répertoire, il ne peut pas lancer de commande qui s'y trouve. Et puis en quoi est ce génant d'avoir accès (en lecture/execution) à /bin

Bonjour, effectivement, cela n'a pas trop de sens avec /bin/ mais il y bien d'autres répertoires /usr/local par exemple ou même les /var/log au sein desquels les utilisateurs pourraient aller récupérer des informations qu'ils ne devraient pas pouvoir lire (config, infos des logs....)

seb0uil

Effectivement pour /var/log, ca peut être plus pertinent. Tu peux toujours changer les accès à ce répertoire. Après, si je regarde sur mon poste, il y en a peu qui sont lisible par un utilisateur lambda

$ ls -rtl |grep 'r-- '
-rw-r--r-- 1 root   root      0 2009-10-04 21:15 pycentral.log
-rw-r--r-- 1 root   root   2931 2009-10-05 20:59 jockey.log.3.gz
-rw-r--r-- 1 root   root   2766 2009-10-05 21:16 fontconfig.log
-rw-r--r-- 1 root   root   4190 2009-10-06 21:50 jockey.log.2.gz
-rw-r--r-- 1 root   root  58556 2009-10-12 22:48 Xorg.failsafe.log.old
-rw-r--r-- 1 root   root  32620 2009-10-21 21:43 jockey.log.1
-rw-r--r-- 1 root   root      0 2009-10-21 21:43 jockey.log
-rw-r--r-- 1 root   root    907 2009-11-09 07:58 kdm.log.5.gz
-rw-r--r-- 1 root   root    908 2009-11-10 07:33 kdm.log.4.gz
-rw-r--r-- 1 root   root    774 2009-11-11 14:23 kdm.log.3.gz
-rw-r--r-- 1 root   root    834 2009-11-13 20:19 kdm.log.2.gz
-rw-r--r-- 1 root   root   1657 2009-11-15 09:40 kdm.log.1
-rw-r--r-- 1 root   root      0 2009-11-15 09:40 kdm.log
-rw-rw-r-- 1 root   utmp 292292 2009-12-11 19:25 lastlog
-rw-r--r-- 1 root   root  32032 2009-12-11 19:25 faillog
-rw-r--r-- 1 root   root   6907 2009-12-30 09:05 pm-suspend.log
-rw-r--r-- 1 root   root   6498 2009-12-30 09:09 Xorg.failsafe.log
-rw-r--r-- 1 root   root    371 2009-12-31 12:08 wpa_supplicant.log.5.gz
-rw-rw-r-- 1 root   utmp 259200 2010-01-01 16:28 wtmp.1
-rw-r--r-- 1 root   root    425 2010-01-01 16:39 wpa_supplicant.log.4.gz
-rw-r--r-- 1 root   root     91 2010-01-02 07:59 wpa_supplicant.log.3.gz
-rw-r--r-- 1 root   root    346 2010-01-03 10:10 wpa_supplicant.log.2.gz
-rw-r--r-- 1 root   root    347 2010-01-04 07:42 wpa_supplicant.log.1.gz
-rw-r--r-- 1 root   root  30325 2010-01-04 08:17 Xorg.0.log.old
-rw-r--r-- 1 root   root 209637 2010-01-04 18:31 udev
-rw-r--r-- 1 root   root   7201 2010-01-04 18:31 dkms_autoinstaller
-rw-r--r-- 1 root   root  29889 2010-01-04 21:09 Xorg.0.log
-rw-r--r-- 1 root   root    187 2010-01-04 21:09 pm-powersave.log
-rw-rw-r-- 1 root   utmp  16512 2010-01-04 22:45 wtmp
-rw-r--r-- 1 root   root   4400 2010-01-04 22:56 wpa_supplicant.log

Dans ce cas, toujours un chmod bien placé, mais il faut vraiment éviter de faire du récursif à la racine

NicolasDa

Je pense qu'il n'existe rien d'autre de toute manière que de faire des tests avec la commande chmod, valider et s'assurer que tout fonctionne toujours après.

Merci à tous pour votre aide.

Hoper

Bon donc visiblement personne comprend rien à ce que je raconte :rolleyes:
ON NE FAIS PAS DE CHMOD SUR LES REPERTOIRES SYSTEMES !

Maintenant libre à toi de tester dans tous les sens, mais tu risque simplement de tout casser. Et encore une fois, je me répète, les fichiers de logs système ou le fichier /etc/group n'ont rien de confidentiel ! Si vraiment tu est dans un environement ou c'est tu pense que c'est le cas (tu bosse à DST ?) alors SI la commande chroot sert justement à cela. chroot ca veut dire "change root". Donc si, pour un utilisateur tu va pouvoir "modifier son /". Sous reserve de lui redonner l'accès aux commandes de base (il aura son propre répértoire bin) il n'aura plus accès à la vraie racine, à /etc et à tout le reste. Il ne pourra voir que "sa" racine.

mais il faut vraiment éviter de faire du récursif à la racine

ou dans n'importe quel répértoire système !

Essaye de taper la commande :

ls -l /usr/bin/passwd

Tu obtient :
-rwsr-xr-x 1 root root 29104 2008-12-08 10:14 /usr/bin/passwd

tu vois le s ? Il est la pas la pour rien ! Et il y a des tas de fichiers avec des permissions particulières. Avec un chmod récursif comme tu le fais tu détruit ses permissions, et donc tu plante ton OS dans la foulée.

Julientroploin

Pour ce qui est du /home/user, il n'était pas prévu pour Jauny ou Karmic de pouvoir le crypter lors de l'utilisation sauf une sous dossier ~/public pour en limiter l'accès justement?

J'ai peut être mal lu à l'époque ou alors ça a été abandonné.

NicolasDa

Hoper a écritBon donc visiblement personne comprend rien à ce que je raconte :rolleyes:
ON NE FAIS PAS DE CHMOD SUR LES REPERTOIRES SYSTEMES !

Je ne dis plus le contraire. Quelqu'un d'autre?

Hoper a écritEssaye de taper la commande :
ls -l /usr/bin/passwd
Tu obtient :
-rwsr-xr-x 1 root root 29104 2008-12-08 10:14 /usr/bin/passwd

tu vois le s ? Il est la pas la pour rien ! Et il y a des tas de fichiers avec des permissions particulières. Avec un chmod récursif comme tu le fais tu détruit ses permissions, et donc tu plante ton OS dans la foulée.

A quoi sert ce "s"? Je vois parfois d'autre lettre (possible)? Quel sont leur signaification? Peux-être connais-tu une page expliquant cela? Je me ferai un plaisir d'aller la lire ;-)

Henry de Monfreid

NicolasDa a écritA quoi sert ce "s"? Je vois parfois d'autre lettre (possible)? Quel sont leur signaification? Peux-être connais-tu une page expliquant cela? Je me ferai un plaisir d'aller la lire ;-)

http://fr.wikipedia.org/wiki/Permissions_Unix#Droit_SGID

seb0uil

tu vois le s ? Il est la pas la pour rien ! Et il y a des tas de fichiers avec des permissions particulières. Avec un chmod récursif comme tu le fais tu détruit ses permissions, et donc tu plante ton OS dans la foulée.

Ca dépend, avec un chmod o-rw... on ne change pas les setuid/setgid etc..., après en faisant un chmod 660, là ca pose pb !!

Mais, après, même sans ces bit particuliers, comme je le mettais, certaines applis refusent de fonctionner si leurs fichier n'ont pas les droits correctement placés.

Après, je pense qu'un OS comme Linux est suffisamment souple pour être 'adaptable' en fonction de chacun, mais effectivement, il vaut mieux savoir ce que l'on fait au risque de planter complétement son système.
(en rappelant toujours qu'un chmod RECURSIF est source de pb)