Je trouve l'argumentation biaisée. À la base, même s'il n'y a qu'un seul utilisateur sur la machine, « root », c'est : cet utilisateur + tout le reste. Il n'y a pas spécialement d'avantage à utiliser root plutôt que son propre compte en temps normal. Ensuite :
l'utilisateur de base à déjà l'accès complet au réseau : « il peut recevoir et envoyer des données à n'importe quel serveur sur n'importe quel port ». Combiné au point précédent, cela signifie que l'utilisateur de base peut se faire voler ses données par n'importe quel programme exécuté avec ses propres droits.
Ça permet aussi et surtout — entre autres choses — à n'importe qui d'ouvrir un port inférieur à 1024. N'importe quel script pourrait par exemple lancer un serveur web sur le port 80 d'une machine-zombie, par exemple.
l'utilisateur de base peut lancer n'importe quel programme. Il lui suffit de le télécharger et de l'exécuter. Donc le compte root ne protège pas les données des virus, il ne protège que les fichiers systèmes (les moins importants).
Même chose : ça limite énormément la portée de ce que peut faire le programme, comme manipuler ou même bronsoniser les processus d'à côté. Au hasard, un httpd un peu chiant qui occuperait déjà le port 80. :-) Même le tableau au milieu de l'article est orienté : « Run installed programs : Root √ ; User : √ ». Ça, ce n'est pas un mal nécessaire, c'est le fonctionnement normal d'un système multitâches : c'est à cela qu'il sert, et ce n'est pas censé être une faille en soi.
Ça veut surtout dire que non seulement éviter d'utiliser root reste une évidence, mais que ce n'est pas suffisant : même en tant qu'utilisateur, il faut prendre des précautions. En tout cas si on est paranoïaque puisque dans le cas contraire, c'est toute cette discussion qui n'a plus d'objet. Et là, par contre : néant. On aurait aimé qu'il parle des principales techniques de compartimentage utilisées sous Unix, comme par exemple l'utilisation de pseudo-utilisateurs : les principaux services comme Apache, Postgresql et Mysql sont presque tous configurés aujourd'hui, pour utiliser le leur. En bossant sous root, il suffit d'un seul kill pour tous les mettre par terre ou corrompre leurs données. En utilisateur normal, sans le mot de passe, point de salut et celui-ci — contrairement à sudo — n'est pas saisi toutes les dix minutes ou stocké en clair à un endroit identique sur toutes les machines (enfin, en principe). Il n'est quand même pas difficile de configurer l'interface graphique de l'utilisateur débutant pour qu'elle lance par défaut un script externe avec l'identité d'un pseudo-utilisateur plutôt que celle de l'utilisateur en cas de doute. On aurait bien aimé également qu'il nous parle de chroot, qui permet de mettre en place relativement facilement un bac à sable pour lancer les applications potentiellement dangereuses.
D'autre part, root n'est pas seulement le vecteur préféré des agressions extérieures : c'est aussi le moyen de réparer son système quand le reste ne marche plus : par exemple, mkfs réserve par défaut 5 % d'espace pour root au moins sur la partition système. Son home dir se trouve également sur une partition distincte ou directement sur la partition système. Ça permet d'une part de se loguer quand on ne peut plus monter /home et de faire tourner le système quand un log fou a rempli sa partition. Bosser en root, c'est contourner volontairement tous les garde-fous mis en place par le système. Enfin, il y a le fait que root n'est un utilisateur normal et que bon nombre de contrôles sont faits directement au niveau du noyau pour savoir si l'uid en vigueur est ou non égale à zéro.
Ça avec le fait que dès que l'on déclara un second (vrai) utilisateur ou lorsque l'on travaillera sur un système centralisé, il faudra perdre toutes ces mauvaises habitudes acquises sans raison valable. Alors pourquoi faire ?
# Pourquoi faire ?
Posté par Obsidian . En réponse au journal Contre la phobie du root. Évalué à 10.
Je trouve l'argumentation biaisée. À la base, même s'il n'y a qu'un seul utilisateur sur la machine, « root », c'est : cet utilisateur + tout le reste. Il n'y a pas spécialement d'avantage à utiliser root plutôt que son propre compte en temps normal. Ensuite :
Ça permet aussi et surtout — entre autres choses — à n'importe qui d'ouvrir un port inférieur à 1024. N'importe quel script pourrait par exemple lancer un serveur web sur le port 80 d'une machine-zombie, par exemple.
Même chose : ça limite énormément la portée de ce que peut faire le programme, comme manipuler ou même bronsoniser les processus d'à côté. Au hasard, un httpd un peu chiant qui occuperait déjà le port 80. :-) Même le tableau au milieu de l'article est orienté : « Run installed programs : Root √ ; User : √ ». Ça, ce n'est pas un mal nécessaire, c'est le fonctionnement normal d'un système multitâches : c'est à cela qu'il sert, et ce n'est pas censé être une faille en soi.
Ça veut surtout dire que non seulement éviter d'utiliser root reste une évidence, mais que ce n'est pas suffisant : même en tant qu'utilisateur, il faut prendre des précautions. En tout cas si on est paranoïaque puisque dans le cas contraire, c'est toute cette discussion qui n'a plus d'objet. Et là, par contre : néant. On aurait aimé qu'il parle des principales techniques de compartimentage utilisées sous Unix, comme par exemple l'utilisation de pseudo-utilisateurs : les principaux services comme Apache, Postgresql et Mysql sont presque tous configurés aujourd'hui, pour utiliser le leur. En bossant sous root, il suffit d'un seul kill pour tous les mettre par terre ou corrompre leurs données. En utilisateur normal, sans le mot de passe, point de salut et celui-ci — contrairement à sudo — n'est pas saisi toutes les dix minutes ou stocké en clair à un endroit identique sur toutes les machines (enfin, en principe). Il n'est quand même pas difficile de configurer l'interface graphique de l'utilisateur débutant pour qu'elle lance par défaut un script externe avec l'identité d'un pseudo-utilisateur plutôt que celle de l'utilisateur en cas de doute. On aurait bien aimé également qu'il nous parle de chroot, qui permet de mettre en place relativement facilement un bac à sable pour lancer les applications potentiellement dangereuses.
D'autre part, root n'est pas seulement le vecteur préféré des agressions extérieures : c'est aussi le moyen de réparer son système quand le reste ne marche plus : par exemple, mkfs réserve par défaut 5 % d'espace pour root au moins sur la partition système. Son home dir se trouve également sur une partition distincte ou directement sur la partition système. Ça permet d'une part de se loguer quand on ne peut plus monter /home et de faire tourner le système quand un log fou a rempli sa partition. Bosser en root, c'est contourner volontairement tous les garde-fous mis en place par le système. Enfin, il y a le fait que root n'est un utilisateur normal et que bon nombre de contrôles sont faits directement au niveau du noyau pour savoir si l'uid en vigueur est ou non égale à zéro.
Ça avec le fait que dès que l'on déclara un second (vrai) utilisateur ou lorsque l'on travaillera sur un système centralisé, il faudra perdre toutes ces mauvaises habitudes acquises sans raison valable. Alors pourquoi faire ?