Je crois que c'est, au contraire, une bonne idée. Après tout, le nom de l'utilisateur est la moitié des informations nécessaires pour accéder un à système.
Bien que je ne changerai pas, de moi-même, le nom de l'uid0 sur une machine qui ne contiens que des informations de faible importance, je pense que je serais fortement tenté de le faire si je sais que la machine en question contiens des informations de haute sécurité. Après... j'avoue, je n'y connais rien en sécurité, je ne suis pas admin.
En fait, ça se fait effectivement parfois, mais c'est de la même façon que tu peux remonter /dev ou /proc sur les répertoires de ton choix, et mettre les bibliothèques où tu veux pourvu que tu règles correctement LD_LIBRARY_PATH et ld.so.conf sous Linux. C'est possible mais c'est aller au devant d'ennuis pour rien.
Certes, changer le nom du root te permet éventuellement de te protéger contre les scripts automatiques les plus simples, mais la liste des utilisateurs est visible à travers /etc/passwd, même si c'est en lecture seule. Donc, c'est une protection qui ne sert à rien contre les attaques en local. Contre les attaques à distance, le plus sage est tout simplement d'interdire à root de se connecter directement.
D'autre part, on ne fait pas de sécurité par l'obscurantisme. Si tu as besoin de t'y connecter à distance pour pouvoir faire du dépannage éventuel, le mieux (à mon avis) est d'utiliser un certificat en plus d'une liaison chiffrée et d'un mot de passe fort.
Justement, c'est cela qui m'intrigue. Linux est considéré comme un fils spirituel d'UNIX (mais moins que les BSD je crois?)
Il y a eu originellement un grand schisme dans le monde UNIX à l'époque où c'était encore le système de quelques grandes compagnies et d'universités prestigieuses, en substance celle de Berkeley. Tu peux visiter SysV sur Wikipédia et la frise d'É. Lévénez qu'on ne présente plus, mais quoi qu'il en soit, deux grandes tendances se sont dessinées : les UNIX basés sur SysV, plus ou moins issu de la lignée originale, et ceux basés sur les travaux de BSD. Il s'est passé en gros la même chose qu'avec Red Hat et Debian dans le monde Linux, ce qui avait donné lieu à une réflexion dans la communauté pour éviter que Linux se scinde lui-même en deux projets.
J'évite d'aller plus loin parce que le fil va se transformer en troll systemd (on est vendredi mais il est encore un peu tôt).
on constate une vérification hard-codée dans mount?
En fait, il y a une raison à cela : si tu écris « ls -l $(which mount) », tu t'apercevras que mount a le bit setuid. Ça veut donc dire qu'il sera automatiquement lancé en root, même si l'utilisateur ne fait rien de spécial. Ceci lui permet d'offrir la possibilité à l'utilisateur de monter ce qui se trouve déjà dans /etc/fstab, si les lignes concernées possèdent l'attribut « user », ou « users » (le premier impose que ce soit l'utilisateur ayant monté le volume qui le démonte, tandis que le second permet à n'importe qui de le faire). Mais évidemment, lancé en tant que root par un admin ou par un utilisateur ordinaire sous son identité, le programme sera donc root dans les deux cas. C'est donc à lui qu'il appartient de vérifier sous quelle identité il a été réellement lancé pour savoir s'il doit honorer n'importe quelle requête ou s'il doit se cantonner à ce qui est déjà dans /etc/fstab. C'est aussi ce qui va introduire les notions d'identité réelle et d'identité effective (getuid() et geteuid()).
Le problème est le même avec la commande « passwd ». Si elle est officiellement lancée en tant que root, elle peut modifier le mot de passe de n'importe qui (utile pour l'administrateur) mais si elle est lancée en tant qu'utilisateur ordinaire, elle ne devra modifier que le mot de passe de cet utilisateur en particulier. Il en reste que, dans les deux cas, le processus doit être privilégié pour modifier le fichier principal des mots de passe.
et le doute m'entraîne à poser des questions, pour comprendre pourquoi les choses que je crois être des erreurs en sont vraiment.
C'est exactement ce qu'il faut faire, mais attention au biais de conformité.
Tu serais donc encore plus horrifié que moi en voyans la façon de... hum... travailler.... de la boîte pour laquelle je bosse. Déjà, on demande à des dev d'être admin de serveurs critiques, en plus, on nous demande de déployer des cibles de test sur les serveurs de prod, et, je te le promets à ma grande honte, il n'y à qu'un seul compte sur ces machines: root. J'y suis depuis presque un an, j'ai toujours râlé et gueulé contre cet état de fait (je ne te parle même pas de l'architecture... ou du manque de... des... logiciels... pissés!
Si tout le monde a le mot de passe root de la machine, profites-en pour te créer un compte à toi, le mettre dans les sudoers, et travailler normalement même si tous tes collègues utilisent tes serveurs comme des bacs à sable. Au moins sur les machines de développement (les prods ont peut-être un master à respecter mais étant donné la ligne directrice, j'en doute un peu).
Si tu as besoin d'une autre analogie : tu peux comparer ça à l'userland et au mode noyau : tout ce qui est dans le noyau (en ring 0 sur Intel) peut écrire partout et accéder aux ports d'entrées-sorties. Tout ce qui est en user (en ring 3), en revanche, ne peut agir que dans son espace et ne peut acquérir des privilèges qu'en faisant un appel système, qui va le faire entrer dans le noyau et exécuter uniquement ce qui s'y trouve déjà.
« root » est le même principe appliqué aux utilisateurs. Le root est omnipotent et lève par nature toutes les restrictions du système. Tous les autres utilisateurs, eux, sont les mêmes a priori. Comme, sous Unix, tout est censé être fichier, on est théoriquement en mesure de donner des droits d'accès à n'importe quoi. C'est aussi pour cela que ça devient pénible quand certains projets (notamment des environnements de bureau) s'éloignent de ce principe pour réinventer ensuite leurs propres méthodes de contrôle.
Le principal danger à travailler sous root ne vient pas des attaques potentielles de l'extérieur : ça lève tous les garde-fous légitimement mis en place. Par exemple, quand on formate une partition et que l'on monte un volume sous Unix, le système a le bon goût de réserver cinq pourcents (par défaut) de cet espace et de le considérer comme plein quand un utilisateur atteint cette limite. Si c'est la partition système qui est concernée (probable s'il n'y en a qu'une seule sur le disque), ça empêche ton système de démarrer correctement, comme partout. Mais le fait d'avoir cette réserve te permet justement de te connecter en root (en mode dégradé ou mono-utilisateur), de faire le ménage et de relancer le système proprement. Si tu travailles tout le temps en root, tu blindes ta partition et le seul moyen de s'en sortir est d'utiliser un LiveCD pour aller le réparer depuis l'extérieur. Et ceci n'est qu'un exemple. Voir également ce journal et les commentaires qu'il a suscité : http://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
erk... ceci dit, j'essaie de réduire la cata... utiliser un CVS et un bugtracker, monter un serveur avec des VM pour le test, et je n'ose imaginer faire un buildbot avec tests unitaires, j'ai déjà assez de résistance au changement comme ça!)
Aujourd'hui, tu as le droit d'utiliser git ou mercurial. CVS est vénérable et le plus répandu parce que le plus ancien (probablement). Il a inspiré tous les suivants mais désormais, il a le droit à une retraite bien méritée. Je n'aime pas beaucoup le changement non plus mais essayer l'un ou l'autre pendant un après-midi suffit à être convaincu et à ne plus revenir en arrière.
Je crois que c'est cette partie là que je ne comprend pas, en fait. Je pense qu'il me faut étudier les effets exacts de ce flag, il n'y à qu'ainsi que je pourrais comprendre pourquoi on teste si le lanceur à l'uid 0 dans mount pour certaines conditions.
« ls -l » permet de voir instantanément les neufs bits des droits d'accès habituels des fichiers : « rwxrwxrwx », soit les droits en lecture, écriture et exécution (ou parcours s'il s'agit d'un répertoire) pour, respectivement, le propriétaire du fichier, les membres du groupe auquel appartient ce fichier, et tous les autres.
Mais il en existe trois autres : setuid, setgid, et le sticky bit. Les deux premiers sont nommés ainsi relativement à la fonction qu'ils semblent appeler. Concrètement, si un utilisateur quel qu'il soit a le droit d'exécuter le fichier (binaire exécutable) et le fait, alors si le bit setuid est posé, le programme sera lancé avec l'UID du propriétaire du fichier et pas celui de la personne qui l'a lancé. Même chose avec setgid() : le processus appartiendra au groupe dans lequel est placé le fichier. Il est important de noter que ce propriétaire (et donc l'UID effective du processus) n'est pas forcément root, mais c'est utilisé à cette fin dans neuf cas sur dix.
Le sticky bit, lui, quand il est placé sur un répertoire, sert à permettre aux utilisateurs de modifier un fichier qui n'est pas le leur si ils en le droit (« w ») mais leur interdire de le supprimer, réservant ce droit au propriétaire du fichier ou du répertoire qui le contient.
[^] # Re: Pas tout seul
Posté par Obsidian . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 5.
En fait, ça se fait effectivement parfois, mais c'est de la même façon que tu peux remonter /dev ou /proc sur les répertoires de ton choix, et mettre les bibliothèques où tu veux pourvu que tu règles correctement LD_LIBRARY_PATH et ld.so.conf sous Linux. C'est possible mais c'est aller au devant d'ennuis pour rien.
Certes, changer le nom du root te permet éventuellement de te protéger contre les scripts automatiques les plus simples, mais la liste des utilisateurs est visible à travers /etc/passwd, même si c'est en lecture seule. Donc, c'est une protection qui ne sert à rien contre les attaques en local. Contre les attaques à distance, le plus sage est tout simplement d'interdire à root de se connecter directement.
D'autre part, on ne fait pas de sécurité par l'obscurantisme. Si tu as besoin de t'y connecter à distance pour pouvoir faire du dépannage éventuel, le mieux (à mon avis) est d'utiliser un certificat en plus d'une liaison chiffrée et d'un mot de passe fort.
Il y a eu originellement un grand schisme dans le monde UNIX à l'époque où c'était encore le système de quelques grandes compagnies et d'universités prestigieuses, en substance celle de Berkeley. Tu peux visiter SysV sur Wikipédia et la frise d'É. Lévénez qu'on ne présente plus, mais quoi qu'il en soit, deux grandes tendances se sont dessinées : les UNIX basés sur SysV, plus ou moins issu de la lignée originale, et ceux basés sur les travaux de BSD. Il s'est passé en gros la même chose qu'avec Red Hat et Debian dans le monde Linux, ce qui avait donné lieu à une réflexion dans la communauté pour éviter que Linux se scinde lui-même en deux projets.
J'évite d'aller plus loin parce que le fil va se transformer en troll systemd (on est vendredi mais il est encore un peu tôt).
En fait, il y a une raison à cela : si tu écris «
ls -l $(which mount)», tu t'apercevras quemounta le bit setuid. Ça veut donc dire qu'il sera automatiquement lancé en root, même si l'utilisateur ne fait rien de spécial. Ceci lui permet d'offrir la possibilité à l'utilisateur de monter ce qui se trouve déjà dans /etc/fstab, si les lignes concernées possèdent l'attribut « user », ou « users » (le premier impose que ce soit l'utilisateur ayant monté le volume qui le démonte, tandis que le second permet à n'importe qui de le faire). Mais évidemment, lancé en tant que root par un admin ou par un utilisateur ordinaire sous son identité, le programme sera donc root dans les deux cas. C'est donc à lui qu'il appartient de vérifier sous quelle identité il a été réellement lancé pour savoir s'il doit honorer n'importe quelle requête ou s'il doit se cantonner à ce qui est déjà dans /etc/fstab. C'est aussi ce qui va introduire les notions d'identité réelle et d'identité effective (getuid() et geteuid()).Le problème est le même avec la commande « passwd ». Si elle est officiellement lancée en tant que root, elle peut modifier le mot de passe de n'importe qui (utile pour l'administrateur) mais si elle est lancée en tant qu'utilisateur ordinaire, elle ne devra modifier que le mot de passe de cet utilisateur en particulier. Il en reste que, dans les deux cas, le processus doit être privilégié pour modifier le fichier principal des mots de passe.
C'est exactement ce qu'il faut faire, mais attention au biais de conformité.
Si tout le monde a le mot de passe root de la machine, profites-en pour te créer un compte à toi, le mettre dans les sudoers, et travailler normalement même si tous tes collègues utilisent tes serveurs comme des bacs à sable. Au moins sur les machines de développement (les prods ont peut-être un master à respecter mais étant donné la ligne directrice, j'en doute un peu).
Si tu as besoin d'une autre analogie : tu peux comparer ça à l'userland et au mode noyau : tout ce qui est dans le noyau (en ring 0 sur Intel) peut écrire partout et accéder aux ports d'entrées-sorties. Tout ce qui est en user (en ring 3), en revanche, ne peut agir que dans son espace et ne peut acquérir des privilèges qu'en faisant un appel système, qui va le faire entrer dans le noyau et exécuter uniquement ce qui s'y trouve déjà.
« root » est le même principe appliqué aux utilisateurs. Le root est omnipotent et lève par nature toutes les restrictions du système. Tous les autres utilisateurs, eux, sont les mêmes a priori. Comme, sous Unix, tout est censé être fichier, on est théoriquement en mesure de donner des droits d'accès à n'importe quoi. C'est aussi pour cela que ça devient pénible quand certains projets (notamment des environnements de bureau) s'éloignent de ce principe pour réinventer ensuite leurs propres méthodes de contrôle.
Le principal danger à travailler sous root ne vient pas des attaques potentielles de l'extérieur : ça lève tous les garde-fous légitimement mis en place. Par exemple, quand on formate une partition et que l'on monte un volume sous Unix, le système a le bon goût de réserver cinq pourcents (par défaut) de cet espace et de le considérer comme plein quand un utilisateur atteint cette limite. Si c'est la partition système qui est concernée (probable s'il n'y en a qu'une seule sur le disque), ça empêche ton système de démarrer correctement, comme partout. Mais le fait d'avoir cette réserve te permet justement de te connecter en root (en mode dégradé ou mono-utilisateur), de faire le ménage et de relancer le système proprement. Si tu travailles tout le temps en root, tu blindes ta partition et le seul moyen de s'en sortir est d'utiliser un LiveCD pour aller le réparer depuis l'extérieur. Et ceci n'est qu'un exemple. Voir également ce journal et les commentaires qu'il a suscité : http://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
Aujourd'hui, tu as le droit d'utiliser git ou mercurial. CVS est vénérable et le plus répandu parce que le plus ancien (probablement). Il a inspiré tous les suivants mais désormais, il a le droit à une retraite bien méritée. Je n'aime pas beaucoup le changement non plus mais essayer l'un ou l'autre pendant un après-midi suffit à être convaincu et à ne plus revenir en arrière.
« ls -l » permet de voir instantanément les neufs bits des droits d'accès habituels des fichiers : « rwxrwxrwx », soit les droits en lecture, écriture et exécution (ou parcours s'il s'agit d'un répertoire) pour, respectivement, le propriétaire du fichier, les membres du groupe auquel appartient ce fichier, et tous les autres.
Mais il en existe trois autres : setuid, setgid, et le sticky bit. Les deux premiers sont nommés ainsi relativement à la fonction qu'ils semblent appeler. Concrètement, si un utilisateur quel qu'il soit a le droit d'exécuter le fichier (binaire exécutable) et le fait, alors si le bit setuid est posé, le programme sera lancé avec l'UID du propriétaire du fichier et pas celui de la personne qui l'a lancé. Même chose avec setgid() : le processus appartiendra au groupe dans lequel est placé le fichier. Il est important de noter que ce propriétaire (et donc l'UID effective du processus) n'est pas forcément root, mais c'est utilisé à cette fin dans neuf cas sur dix.
Le sticky bit, lui, quand il est placé sur un répertoire, sert à permettre aux utilisateurs de modifier un fichier qui n'est pas le leur si ils en le droit (« w ») mais leur interdire de le supprimer, réservant ce droit au propriétaire du fichier ou du répertoire qui le contient.