Pourquoi est-il mauvais de se connecter en tant que root?

Question

J'ai souvent rencontré des publications sur des forums ou sur d'autres sites Web où vous voyez des gens plaisanter de manière à exécuter/se connecter en tant que root, comme si c'était horrible et que tout le monde devrait le savoir. Cependant, il n'y a pas grand chose qu'une recherche révèle sur le sujet.

Il est peut-être largement connu des experts Linux, mais je ne sais vraiment pas pourquoi. Je me souviens d'avoir toujours fonctionné en tant que root lorsque j'ai essayé Linux pour la première fois il y a quelques années (Redhat et Mandrake) et je ne me souviens pas d'avoir rencontré de problèmes pour cette raison.

Il y a en fait des distributions qui ont un fond rouge vif avec des signes d'alerte partout comme papier peint pour l'utilisateur root (SuSe?). J'utilise toujours le compte "Administrateur" pour une utilisation régulière sur mon installation Windows et je n'y ai jamais rencontré de problèmes.

lazyPower · Accepted Answer

Cela va à l'encontre du modèle de sécurité en place depuis des années. Les applications sont conçues pour fonctionner avec une sécurité non administrative (ou en tant que simples mortels), vous devez donc élever leurs privilèges pour modifier le système sous-jacent. Par exemple, vous ne voudriez pas que la récente panne de Rhythmbox efface tout votre répertoire /usr à cause d'un bogue. Ou cette vulnérabilité qui vient d'être publiée dans ProFTPD pour permettre à un attaquant d'obtenir un shell ROOT.

Il est recommandé, sur tout système d'exploitation, d'exécuter vos applications au niveau utilisateur et de laisser les tâches administratives à l'utilisateur root, uniquement au besoin.

Vojtech Trefny · Answer

Juste un mot: sécurité.

Vous êtes connecté en tant qu'utilisateur root = toutes les applications s'exécutent avec les privilèges root. Toute vulnérabilité dans Firefox, Flash, OpenOffice, etc. peut maintenant détruire votre système, car de possibles virus ont désormais accès partout. Oui, il n’ya que peu de virus pour Ubuntu/Linux, mais c’est aussi pour des raisons de sécurité et d’utilisateur par défaut sans privilège.
Il ne s'agit pas uniquement de virus - un petit bogue dans une application pourrait effacer certains fichiers système ou ...
Lorsque vous êtes connecté en tant que root, vous pouvez tout faire - le système ne vous le demandera pas! Voulez-vous formater ce disque? Ok, juste un clic et c'est fait, car vous êtes root et vous savez ce que vous faites ...

Marlon · Answer

Courir en tant que root est mauvais parce que:

Stupidité: Rien ne vous empêche de faire une bêtise. Si vous essayez de modifier le système de quelque manière que ce soit qui pourrait être dangereux, vous devez utiliser Sudo, ce qui vous garantit une pause pendant la saisie du mot de passe pour vous permettre de réaliser que vous êtes sur le point d'effectuer un changement important/coûteux.
Sécurité: Il a déjà été mentionné à plusieurs reprises dans cette question, mais au fond, c'est la même chose, plus difficile à pirater si vous ne connaissez pas le compte de connexion de l'utilisateur admin. root signifie que vous disposez déjà de la moitié des informations d'identification d'administrateur.
Vous n'en avez pas vraiment besoin: Si vous devez exécuter plusieurs commandes en tant que root et que vous êtes ennuyé de devoir entrer votre mot de passe plusieurs fois lorsque Sudo a expiré, il vous suffit de Sudo -i et vous êtes maintenant root. Vous voulez exécuter des commandes à l'aide de pipes? Ensuite, utilisez Sudo sh -c "comand1 | command2".
Vous pouvez toujours l'utiliser dans la console de récupération: La console de récupération vous permet d'essayer de récupérer d'une bêtise ou de résoudre un problème causé par une application (que vous deviez toujours exécuter en tant que Sudo :)) Dans ce cas, Ubuntu n’a pas de mot de passe pour le compte root, mais vous pouvez effectuer une recherche en ligne pour changer cela. Cela rendra plus difficile la tâche de quiconque ayant un accès physique à votre ordinateur peut faire du mal.

La raison pour laquelle vous n’avez pas pu trouver d’informations sur les raisons pour lesquelles ces problèmes sont graves, c’est parce qu’il ya trop de données sur Internet :) et que beaucoup de personnes qui utilisent Linux depuis longtemps pensent comme vous. Cette façon de penser sur le compte root est relativement nouvelle (une décennie peut-être?) Et beaucoup de gens sont encore ennuyés de devoir utiliser Sudo. Surtout s’ils travaillent sur un serveur, c’est-à-dire qu’ils ont décidé d’apporter des modifications au système. Probablement provoqués par de mauvaises expériences et des normes de sécurité précédentes, la plupart des administrateurs système connaissent mieux mais ne l'aiment toujours pas :).

loevborg · Answer

C'est une bonne question. Je pense que la réponse est légèrement différente selon que vous parlez d'un serveur ou d'une installation de bureau.

Sur un ordinateur de bureau, il est rare d'utiliser le compte root. En fait, Ubuntu est livré avec un accès root désactivé. Toutes les modifications nécessitant des privilèges de superutilisateur sont effectuées via Sudo et ses équivalents graphiques gksudo et kdesudo. Étant donné qu'il est facile de définir un mot de passe root, cependant, pourquoi les gens ne le font-ils pas?

Une des raisons est que cela vous donne une couche de sécurité supplémentaire. Si vous exécutez un programme en tant que root et qu'une faille de sécurité est exploitée, l'attaquant a accès à toutes les données et peut contrôler directement le matériel. Par exemple, il se peut qu’il installe un cheval de Troie ou un enregistreur de frappe dans votre noyau. En pratique cependant, une attaque peut faire beaucoup de dégâts même sans les privilèges de superutilisateur. Après tout, toutes les données utilisateur, y compris les documents et les mots de passe stockés, sont accessibles sans accès root.

Un point plus valide, sur un système mono-utilisateur, est qu'il est impossible d'empêcher l'utilisateur de rendre accidentellement le système inutilisable. Si l'utilisateur lance involontairement une commande qui supprime tous les fichiers, il pourra toujours démarrer le système, même si les données sont perdues.

De plus, la plupart des applications (X11) actuelles sont conçues sur le principe qu'elles sont exécutées sous un compte utilisateur normal et sans droits d'administrateur. Ainsi, certains programmes risquent de mal fonctionner lorsqu'ils sont exécutés sous la forme root.

Sur un système multi-utilisateur avec un accès Shell non graphique uniquement, bon nombre de ces raisons ne s'appliquent pas. Cependant, Ubuntu utilise toujours un compte root inaccessible. D'une part, il existe une réelle différence entre l'accès à un compte utilisateur (doté de droits Sudo) via une faille de sécurité et l'accès à root, car dans le premier cas, perturber d'autres utilisateurs nécessitera l'exécution de Sudo et continuera à demander le compte. mot de passe comme une étape de sécurité supplémentaire. D'autre part, il est utile d'effectuer de nombreuses tâches administratives à partir d'un compte utilisateur et d'appeler uniquement Sudo lorsque les privilèges de superutilisateur sont absolument nécessaires. Ainsi, lors de l’installation d’un programme à partir des sources, il est conseillé de créer la source - en exécutant configure et make - dans le répertoire de l’utilisateur et en utilisant uniquement Sudo make install à la dernière étape. Encore une fois, il est plus difficile de se tirer dans le pied (et d’autres utilisateurs du système multi-utilisateurs), et cela diminue la probabilité que les scripts de construction fassent des ravages avec le système. Ainsi, même sur un serveur, il est conseillé de s'en tenir à administration basée sur Sudo de Ubuntu.

Jonathan Leffler · Answer

La traçabilité est une des raisons pour ne pas fonctionner en tant que racine qui n'a pas (jusqu'à présent) été identifiée par d'autres réponses. Cela importe probablement moins sur les machines composées principalement d'un seul utilisateur (votre ordinateur de bureau ou votre ordinateur portable), mais sur les machines de serveur, si quelqu'un est connecté sous le nom rootname__, vous ne savez pas qui est responsable des actions entreprises. Par conséquent, la plupart des organisations professionnelles avec plusieurs systèmes et plusieurs administrateurs ayant besoin de privilèges rootexigent que les personnes se connectent avec leur propre ID utilisateur (et mot de passe), puis utilisent Sudoou des programmes similaires pour fonctionner avec les privilèges rootsi nécessaire.

Sinon, les principales raisons de ne pas s'exécuter en tant que root sont les suivantes:

Minimiser les risques de dommages causés par des accidents. Si vous exécutez rm -fr / home/me/my-subdir en tant que root, vous supprimez de la machine tout ce qui est important, à cause de cet espace après la (première) barre oblique. En effet, les éléments qui entrent en premier sont ceux qui ont été ajoutés en premier. , le /bin et le /etc. Unix s'énerve si vous les perdez.
Minimisez les risques de dommages causés par des sites extérieurs malveillants. Si vous naviguez en tant que rootname__, vous êtes presque vulnérable aux téléchargements intempestifs de contenus malveillants.

J'utilise plus MacOS X que Ubuntu, mais la racine est désactivée par défaut et elle se trouve toujours sur ma machine. Je mets régulièrement à niveau le noyau et d’autres opérations similaires en utilisant Sudo(en coulisse). Des techniques similaires s'appliquent à Linux en général.

Fondamentalement, vous ne devriez utiliser que les privilèges tout-puissants de rootpour des périodes de travail abrégées afin d'éviter le risque d'erreur.

Eliah Kagan · Answer

TL; DR: Ne faites les choses en tant que root que lorsque vous devez. Sudo rend cela très facile. Si vous activez les connexions à la racine, vous pouvez toujours suivre cette règle, vous devez juste faire attention à le faire. parce que vous avez Sudo.

Il y a vraiment deux questions connexes ici.

Pourquoi est-il mauvais de se connecter en tant qu'utilisateur root pour une utilisation quotidienne de l'ordinateur (navigation sur le Web, messagerie électronique, traitement de texte, jeux, etc.)?
Pourquoi Ubuntu désactive-t-il par défaut les connexions root et utilise-t-il Sudo et polkit pour permettre aux administrateurs d’exécuter des commandes spécifiques en tant que root?

Pourquoi ne pas tout exécuter en tant que root, tout le temps?

La plupart des autres réponses couvrent cela. Cela revient à:

Si vous utilisez des pouvoirs de racine pour des tâches qui ne les nécessitent pas et que vous finissez par faire quelque chose que vous ne vouliez pas faire, vous pouvez modifier ou endommager votre système d'une manière que vous ne souhaitez pas.
Si vous exécutez un programme en tant que root alors que vous n'en aviez pas besoin, et it == finit par faire quelque chose que vous ne vouliez pas faire - par exemple, à cause d'un faille de sécurité ou autre bogue - cela pourrait changer ou endommager votre système d’une manière que vous ne souhaitiez pas.

Il est vrai que même sans faire les choses en tant que root, vous pouvez causer du tort. Par exemple, vous pouvez supprimer tous les fichiers de votre propre répertoire de base, qui comprend généralement tous vos documents, sans exécuter en tant que root! (J'espère que vous avez des sauvegardes.)

Bien sûr, en tant que root, il existe d'autres moyens de détruire accidentellement ces mêmes données. Par exemple, vous pouvez spécifier le mauvais argument of= dans une commande dd et écrire des données brutes sur vos fichiers (ce qui les rend beaucoup plus difficiles à récupérer que si vous les supprimiez simplement).

Si vous êtes la seule personne à utiliser votre ordinateur, les dommages que vous ne pouvez causer qu'en tant que root pourraient ne pas être plus importants que ceux que vous pouvez causer avec vos privilèges d'utilisateur habituel. Mais ce n’est toujours pas une raison pour étendre votre risque d’inclure d’autres moyens de tout gâcher votre système Ubuntu.

Si le fait d’exécuter avec un compte utilisateur non root vous empêchait d’exercer un contrôle sur votre propre ordinateur, il s’agirait bien entendu d’un compromis bad . Mais ce n'est pas - chaque fois que vous souhaitez == effectuer une action en tant que root, vous pouvez le faire avec Sudo et d'autres méthodes .

Pourquoi ne pas rendre possible la connexion en tant que root?

L'idée que la possibilité de se connecter en tant que root ne soit pas sécurisée est un mythe. Certains systèmes ont un compte root activé par défaut; Les autres systèmes utilisent Sudo par défaut, et certains sont configurés avec les deux.

Par exemple, OpenBSD , qui est largement et raisonnablement considéré comme le système d'exploitation polyvalent le plus sécurisé du monde, est livré avec le compte root activé pour la connexion locale, basée sur un mot de passe.
Parmi les autres systèmes d'exploitation bien respectés, citons RHEL , CentOS et Fedora .
Debian (à partir de laquelle Ubuntu dérive ) l’utilisateur décide quelle approche sera configurée lors de l’installation du système.

Il n’est pas objectivement faux d’avoir un système sur lequel le compte root est activé à condition que

vous ne l'utilisez toujours que lorsque vous en avez vraiment besoin, et
vous en restreignez l'accès de manière appropriée.

Les novices demandent souvent comment activer le compte root dans Ubuntu. Nous ne devrions pas leur cacher cette information, mais généralement quand les gens le demandent, c'est parce qu'ils ont la fausse impression qu'ils need pour activer le compte root. En fait, cela n’est presque jamais nécessaire, il est donc important de répondre à de telles questions . L’activation du compte root facilite également le passage à la suffisance et effectuer des actions en tant que root ne nécessitant pas de privilèges root. Mais cela ne signifie pas que l'activation du compte root est par lui-même non sécurisé.

Sudo encourage et help les utilisateurs exécutent les commandes en tant que root uniquement lorsqu'ils en ont besoin. Pour exécuter une commande en tant que root, tapez Sudo, un espace, puis la commande. C'est très pratique, et de nombreux utilisateurs de tous les niveaux de compétence préfèrent cette approche.

En bref, vous n'avez pas besoin d'activer les connexions à la racine car vous avez Sudo. Mais tant que vous ne l'utilisez que pour les tâches administratives qui en ont besoin, il est tout aussi sécurisé d'activer et de vous connecter en tant que root, tant que c'est de cette façon :

Localement, depuis une console virtuelle non graphique .
Avec la commande su lorsque vous êtes connecté à partir d'un autre compte.

Cependant, des risques de sécurité supplémentaires importants surviennent si vous vous connectez en tant que root de la manière suivante:

Graphically. Lorsque vous vous connectez graphiquement, de nombreuses tâches sont exécutées pour fournir l'interface graphique. Vous devrez donc exécuter encore plus d'applications en tant qu'utilisateur root pour pouvoir utiliser cette interface à tout moment. . Cela va à l’encontre du principe selon lequel seuls les programmes exécutés en tant que root ont vraiment besoin de privilèges root. Certains de ces programmes peuvent contenir des bogues, notamment des problèmes de sécurité.

En outre, il existe une raison non liée à la sécurité pour éviter cela. La connexion graphique en tant que root n’est pas bien prise en charge - , comme le dit loevborg , les développeurs d’environnements de bureau et d’applications graphiques ne les testent pas souvent en tant que root. Même s’ils le font, la connexion à un environnement de bureau graphique en tant qu’utilisateur root ne permet pas aux utilisateurs d’effectuer des tests alpha et bêta dans le monde réel, car presque personne ne le tente (pour les raisons de sécurité expliquées ci-dessus).

Si vous devez exécuter une application graphique spécifique en tant que root, vous pouvez utiliser gksudo ou Sudo -H . Cela exécute beaucoup moins de programmes en tant que root que si vous vous êtes connecté graphiquement avec le compte root.
à distance. Le compte root peut en effet tout faire et il porte le même nom sur pratiquement tous les systèmes de type Unix. En vous connectant en tant qu'utilisateur root via ssh ou d'autres mécanismes distants, ou même par en configurant les services distants pour l'autoriser , vous simplifiez grandement la tâche des intrus, notamment des scripts automatisés et des logiciels malveillants s'exécutant sur des botnets. , pour avoir accès par la force brute, les attaques par dictionnaire (et éventuellement quelques bugs de sécurité).

On peut soutenir que le risque n'est pas extrêmement élevé si vous autorisez uniquement basé sur une clé , et non basé sur un mot de passe connexions à la racine.

Par défaut, dans Ubuntu, ni les connexions graphiques à la racine ni les connexions distantes via SSH ne sont activées, même si vous activez la connexion en tant que root . C'est-à-dire que même si vous activez la connexion root, elle ne l'est toujours que d'une manière raisonnablement sécurisée.

Si vous exécutez un serveur ssh sur Ubuntu et n’avez pas changé de /etc/sshd/ssh_config, il contiendra la ligne PermitRootLogin without-password. Cela désactive la connexion root basée sur un mot de passe, mais permet la connexion basée sur une clé. Cependant, aucune clé n'est configurée par défaut. Par conséquent, à moins d'en avoir configuré une, cela ne fonctionnera pas non plus. De plus, la connexion root à distance basée sur clé est beaucoup moins mauvaise que la connexion root à distance basée sur mot de passe, en partie parce qu'elle ne crée pas le risque d'attaques brutales et d'attaques par dictionnaire.
Même si les valeurs par défaut devrait vous protéger, je pense que c'est toujours une bonne idée de vérifier votre configuration ssh si vous voulez activer le compte root. Et si vous utilisez d'autres services fournissant un login à distance, comme ftp, vous devriez également les vérifier.

En conclusion:

Faites des choses en tant que root seulement quand vous en avez besoin Sudo vous aide à le faire, tout en vous donnant tout le pouvoir de root à tout moment.
Si vous comprenez le fonctionnement de root et les dangers d'une utilisation excessive, l'activation du compte root ne pose pas vraiment de problème du point de vue de la sécurité.
Mais si vous comprenez cela, vous savez aussi que vous ne le faites certainement pas need pour activer le compte root .

Pour plus d'informations sur root et Sudo, y compris quelques avantages supplémentaires de Sudo que je n'ai pas abordés ici, je recommande vivement RootSudo dans le wiki de l'aide Ubuntu.

karthick87 · Answer

Le compte racine est désactivé par défaut, ce qui signifie qu'il existe mais qu'il n'est pas utilisable (sauf en mode de récupération). Cela signifie qu'un attaquant connaît votre compte root, mais ne peut pas l'utiliser même s'il dispose du mot de passe root. Ainsi, un attaquant doit deviner à la fois un nom d’utilisateur disposant des privilèges d’administrateur ET le mot de passe de cet utilisateur (ce qui est beaucoup plus difficile que de simplement essayer de trouver le mot de passe root) .In XP si vous avez le Sur la console de récupération installée, toute personne ayant un accès physique à votre boîte peut y démarrer (RC) - aucun mot de passe n'est requis. Identique au mode de récupération sous Ubuntu.

Dans Ubuntu, quand ils disent que la racine est désactivée, cela signifie en réalité que le compte est verrouillé. Un compte est verrouillé en modifiant le mot de passe en une valeur qui ne correspond à aucune valeur cryptée possible. Ceci empêche efficacement quiconque de pouvoir se connecter en tant que root - car il serait impossible pour eux de saisir le mot de passe. Comme il est encore parfois nécessaire d'accéder à la racine, le noyau Ubuntu a été modifié pour permettre la connexion locale root uniquement en mode mono-utilisateur.

Voir aussi ceci page

omeid · Answer

C'est comme armer un petit enfant avec un AK47, alors qu'il peut jouer avec son pistolet de paintball. ;)

Je veux dire que c'est faux parce que vos applications et vous-même aurez plus de privilèges que nécessaire, et c'est à ce moment-là que les choses peut et le seront parfois vont mal :(

Philip · Answer

Très belle question ... Permettez-moi de répondre d'un point de vue pratique:

Lorsque j'ai commencé à utiliser Linux, il y a plus de 10 ans, les principales distributions n'utilisaient pas autant de comptes non root qu'aujourd'hui. Comme j'étais habitué à Windows, je ne voyais pas non plus l'intérêt d'utiliser un compte d'utilisateur contraint. En particulier parce que je devais entrer "su" très souvent - Sudo n'était pas si populaire à l'époque. ;-) Je me suis donc toujours connecté en tant que root car j'avais beaucoup de maintenance à faire pour que mon système soit bien configuré. Mais devinez quoi, tout système nouvellement installé devient rapidement très instable.

Un problème concret, par exemple: je n’ai pas eu autant d’espace disque dur réservé à Linux, il m’est donc arrivé à quelques reprises de ne plus avoir que 0 octets sur ma partition. Peut-être que je ne suis pas tout à fait précis car je ne connais pas le mécanisme exact, mais lorsque vous remplissez un disque avec un compte non-root, il reste toujours quelques kilo-octets. Mais s'il vous reste vraiment 0 octets, votre système commet des erreurs étranges et vous risquez de subir des dommages difficiles à réparer, car de nombreux logiciels système fonctionnent en arrière-plan ...

Une autre chose est la suivante: cette division entre racine et non-racine maintient votre système bien organisé. En tant qu'utilisateur root, vous pourriez être tenté de ne pas installer proprement vos nouvelles applications, ce qui vous laisse avec un système sale et maintenable.

Mais le point positif est que les distributions modernes effectuent la plupart des tâches d’administration à votre place. Il est donc rare que vous ayez à bricoler les entrailles de votre système Linux avec un compte root. Entrer un mot de passe de temps en temps est suffisant, le reste est fait par les scripts du distributeur.

Mais je doute que votre système Windows ne vous pose pas de problèmes si vous en utilisiez 95 ou 98. (Au moins, je rencontrais des problèmes avec cela ...) en raison de l’absence de séparation claire entre l’administrateur et l’utilisateur régulier "traditionnel". "Les applications Windows supposent qu'elles peuvent tout faire, par exemple installez les logiciels espions s’ils en ont envie, même sans vous le dire. Microsoft s'est engagé dans ce problème lors de la publication de Vista. (Implémentation efficace d'un mécanisme Sudo.) Les gens ont donc eu des dialogues très ennuyeux disant "Vous ne pouvez pas faire ça". Pour certains logiciels non compatibles avec Vista, vous aviez besoin de quelques astuces pour l'installer, même en tant qu'administrateur ...

aneeshep · Answer

Cette approche comporte de nombreux aspects. Certains d'entre eux sont:

La racine est toute puissante.

L'utilisateur root peut masquer toutes ses actions.

Le mot de passe root vous donne accès à toutes les commandes d'un système.

voici un bon article: http://cf.stanford.edu/policy/root

bambuntu · Answer

rm /*

Disons que vous avez nettoyé une zone administrative. Vous en avez assez du mot de passe, alors vous Sudo su. Vous êtes distrait juste une seconde et vous oubliez cd à /. Alors vous rm *. Je l'ai fait. Vous pouvez tout récupérer, mais c'est un PITA. Oh, et il est descendu dans /media aussi!

thomasrutter · Answer

Pourquoi ne pas avoir la connexion root?

Bien que vous puissiez créer un mot de passe pour le compte superutilisateur vous permettant de vous connecter en tant que root, il est à noter que ce n'est pas la méthode de "Ubuntu". faire des choses. Ubuntu a spécifiquement choisi et non de donner un nom d'utilisateur et un mot de passe root par défaut pour une raison. Au lieu de cela, une installation Ubuntu par défaut utilisera Sudoname__.

Sudo est une alternative à donner aux gens un mot de passe root pour effectuer des tâches de superutilisateur. Dans une installation par défaut d’Ubuntu, la personne qui a installé le système d’exploitation reçoit par défaut l’autorisation "Sudo".

Toute personne disposant de l'autorisation "Sudo" peut effectuer quelque chose "en tant que superutilisateur" en mettant en attente Sudodans sa commande. Par exemple, pour exécuter apt-get dist-upgrade en tant que superutilisateur, vous pouvez utiliser:

Sudo apt-get dist-upgrade

Avantages de l'approche Sudo

Avec Sudo, vous choisissez à l’avance quels utilisateurs ont accès à Sudo. Ils n'ont pas besoin de se souvenir d'un mot de passe root car ils utilisent leur propre mot de passe.
Si vous avez plusieurs utilisateurs, vous pouvez révoquer son accès superutilisateur en supprimant simplement leur autorisation Sudo, sans qu'il soit nécessaire de changer le mot de passe root et d'informer tout le monde d'un nouveau mot de passe.
Vous pouvez même choisir les commandes qu'un utilisateur est autorisé à exécuter à l'aide de Sudo et celles qui sont interdites pour cet utilisateur.
Enfin, en cas d’infraction à la sécurité, une meilleure trace d’audit peut dans certains cas laisser apparaître le compte d’utilisateur compromis.

Sudo facilite l'exécution d'une commande unique avec les privilèges de superutilisateur. Avec une connexion root, vous restez en permanence dans un super-utilisateur Shell à quitter avec exitou logoutname__. Cela peut amener les utilisateurs à rester dans le superutilisateur Shell plus longtemps que nécessaire simplement parce que cela est plus pratique que de se déconnecter et de se reconnecter plus tard.

Avec Sudo, vous avez toujours la possibilité d’ouvrir un shell superutilisateur permanent (interactif) avec la commande:

Sudo su

... et cela peut toujours être fait sans mot de passe root, car Sudodonne des privilèges de superutilisateur à la commande suname__.

Et de même, au lieu de su - pour un shell de connexion, vous pouvez utiliser Sudo su - ou même Sudo -i.

Cependant, pour ce faire, vous devez simplement savoir que vous agissez en tant que superutilisateur pour chaque commande. C'est un bon principe de sécurité de ne pas rester super-utilisateur plus longtemps que nécessaire, juste pour réduire les risques d'endommager accidentellement le système (sans lui, vous ne pouvez endommager que les fichiers que votre utilisateur possède).

Juste pour clarifier, vous pouvez , si vous le souhaitez, donner à l'utilisateur root un mot de passe lui permettant de se connecter en tant que root, si vous souhaitez spécifiquement procéder ainsi à la place. . Je voulais simplement vous informer de la convention Ubuntu consistant à préférer Sudoà la place et essayer d’expliquer certains des motifs pour lesquels Ubuntu privilégie cette approche par défaut.

Pourquoi ne pas autoriser la connexion root sur SSH?

Même si votre utilisateur root a un mot de passe vous permettant de vous connecter en tant que root, il est recommandé de désactiver le login direct à la racine depuis l'extérieur, comme dans SSH. Il est raisonnable que les utilisateurs aient à su - ou Sudoaprès la connexion initiale.

Les avantages potentiels sont principalement liés à la sécurité:

Il réduit le vecteur d'attaque en éliminant la possibilité de forcer brute le mot de passe root à distance. Il est typique qu'un serveur sur Internet soit constamment bloqué par des tentatives visant à forcer brutalement le mot de passe root via SSH.
Cela crée une meilleure piste d'audit de sorte que même en cas de violation où l'attaquant obtienne plus tard les privilèges de superutilisateur, vous pouvez voir quel compte a été utilisé. obtenir l'accès.

Gersitar · Answer

Une fois connecté en tant que root, les applications, les scripts ou les commandes en ligne de commande peuvent accéder aux parties sensibles des logiciels susceptibles d'endommager le système. Cela peut être dû à l'inexpérience de la part de l'utilisateur ou du programmeur ou à un code caché malveillant.

Abel · Answer

C'est tout simplement trop facile de gâcher lorsque vous utilisez root. Vous pouvez écraser tout le système en une seule commande ...

Aleksei · Answer

Je peux ajouter qu'il existe une différence entre Administrateur sous Windows et Racine sous Unix. L'administrateur a toujours certaines restrictions dans les systèmes, où la racine n'a pas de restriction aucune. L’analogue correct de la racine dans Windows est l’utilisateur System .

La mauvaise chose à utiliser PC sous root/système est que vous pouvez détruire n'importe quoi accidentellement sans aucun avertissement de l'OS.

Que · Answer

Raisons contre l'utilisation de root:

Pourrait détruire accidentellement des fichiers système
Pourrait avoir une infection
Ne pas enregistrer les actions

Raisons pour utiliser root:

Accès à tout, pas de mots de passe
Interface graphique, pas d'utilisation de terminaux pour gérer les fichiers/répertoires du système

Il me semble qu'un compte non root pourrait toujours être victime de ces raisons contre l'utilisation de root, tout ce qu'il ajoute est une confirmation de vos actions. Je pense que tant que vous savez ce que vous faites, vous utilisez parfaitement root. Là, je l'ai dit.

segfault · Answer

Si les applications sont exécutées en tant que root, rien ne garantit qu'aucune d'entre elles ne s'exécutera.

rm -rf /

(Ceci est un exemple de commande qui devrait pas être exécutée.)

Clayton · Answer

Étant donné un utilisateur averti et attentif, je ne suis pas sûr qu'une réponse à droite existe. Je n'avais pas vu cette réponse, alors j'ai pensé y aller.

Ce que je n’aime pas, c’est les changements non intentionnels de autorisations sur des systèmes multi-utilisateurs dont j’ai besoin pour chmod plus tard. Réparer via chmod après coup est beaucoup plus irritant que d’avoir besoin de Sudo, mais cela dépend de ce que j’ai prévu.

Bulat M. · Answer

Il n'y a aucun danger à se connecter en tant que root s'il est utilisé avec précaution.

Bien que je pense que la désactivation de root est la solution préférable, car l'attaquant ne pourrait pas le forcer brutalement.

Une solution consiste à créer un utilisateur dans le groupe Sudo avec un nom obscur, tel que gamer et à utiliser Sudo pour effectuer des tâches administratives.

Par conséquent, l'attaquant doit non seulement deviner le mot de passe de cet administrateur, mais également son identifiant. Ce qui n’est pas évident si l’utilisateur utilisant Sudo a un nom de connexion tel que kitty ou gamer ou quelque chose de similaire.

Pavlos G. · Answer

Le logiciel est basé sur des bibliothèques partagées, des dépendances, des fichiers de configuration, etc.
La plupart du temps, un simple clic dans une application invoque une "réaction en chaîne" composée de multiples modifications, pas seulement là où vous pensez que ce serait probablement le cas.
Lorsque ces modifications sont sur le point d'affecter les paramètres critiques du système, vous avez intérêt à le savoir, en tant qu'utilisateur.
C'est pourquoi l'accès root est un bon modèle de sécurité:
Si quelque chose de crucial est sur le point d'arriver à votre système, vous serez averti par un message vous demandant d'élévation de privilèges.

sjas · Answer

C'est un problème double face avec plus d'une réponse.

Pour vous donner une idée de la réalité, répondez toujours à cette question:

desktop installations:

utilisez votre propre utilisateur et Sudo si besoin est, sinon un vecteur d’attaque utilisé avec succès parce que vous ne savez pas vraiment ce que vous faites et que votre système est compromis
dans les grandes entreprises, il est probable que vous ne puissiez même pas avoir les privilèges root sur votre propre poste de travail, même si vous êtes administrateur, en fonction du nombre de chapeaux en étain présents.

server installations:

il y a une grande différence entre faire de vos courtes sessions de travail légitimes en tant que root (à condition que vous disposiez de connexions sans mot de passe, d'une gestion appropriée des clés ssh pour tous les serveurs - et de fail2ban configuré pour toutes les connexions par mot de passe lorsque vous y êtes); avoir chaque démon/service courir avec son propre utilisateur (ce qui est indispensable) - la plupart des gens ne semblent pas se rendre compte de la différence
pour le plaisir: essayez d'utiliser vos outils de gestion de la configuration contrôlés par la version (ansible/puppet/salt/que ce soit avec les fichiers d'un serveur git) uniquement sans accès root. (vous avez une forme d'AAA en place pour ces systèmes spéciaux, ainsi que pour vos systèmes de surveillance et de sauvegarde, n'est-ce pas?)
aussi: default rm -rf / ne fonctionne pas dans la plupart des distributions grand public IIRC
tout lieu de travail sérieux a un hôte jumphost/bastion pour accéder au parc de serveurs qui enregistre tout ce que vous faites de toute façon, ce qui est probablement davantage protégé par 2FA
si vous avez Sudo et pas de jumphost, vous pouvez corriger les journaux des hôtes pour qu'ils finissent comme vous le souhaitez, s'ils ne sont pas mis en miroir en temps réel, c'est-à-dire.
quand également les journaux ssh sont "nettoyés", on ne peut même pas prouver qu'ils se trouvaient sur l'hôte, s'il n'y a plus de système de surveillance du réseau en place

Quelle que soit la taille de l'entreprise (lire: très probablement SOHO avec une adresse IP statique) entre ces deux extrêmes qui ne disposent pas de mesures de surveillance/sauvegarde/automatisation/journalisation décentes, il peut être utile de renforcer l'utilisation de Sudo sur des serveurs. (Ce qui est contourné par les gens qui font Sudo su - ASAP après avoir établi la connexion, laissant toutes leurs intentions de journaliser ce qui s’est passé, même sans intentions malveillantes, dès que plus d’un utilisateur root est connecté. Bonne chance pour changer cela par des procédures forcées et traiter les personnes avec mesures draconiennes pour ne pas respecter les règles. La vie trouve toujours un moyen.)

Mais si vous n'avez pas au moins fail2ban pour sécuriser vos identifiants de mot de passe (en cas de présence, en particulier sur les systèmes Internet), veillez également à la gestion correcte des mots de passe (outils de gestion des mots de passe, stratégies de conservation, aucun mot de passe principal, à gérer par les employés). fluctuations ...) et ont mis en place une forme de gestion appropriée des mises à jour de la flotte de serveurs, de sorte que tous les serveurs sont corrigés régulièrement, vous risquez probablement d'être piraté un jour, que ce soit de l'intérieur ou de à l'extérieur.

Et toujours avoir utilisé Sudo religieusement et imposé son utilisation à tout le monde ne changera pas votre probabilité de devenir propriétaire dans ce cas.

Corky · Answer

En fin de compte, il n’ya pas de mal à courir en tant que root. C'est juste un groupe de personnes paranoïaques qui pensent qu'il est impossible de réinstaller un système d'exploitation. L'argument "Quelqu'un pourrait compromettre un programme ..", et alors? s'ils le font, ils peuvent déjà enregistrer votre mot de passe par saisie de clé ou simplement afficher une demande de mot de passe root et leur demander de fournir le mot de passe. Souffler votre système parce que vous sélectionnez tout et/ou supprimez? eh bien, sortez l'installateur et réinstallez-le. Cela prend moins de 20 minutes, prenez un café et détendez-vous. La racine va bien, je suis la racine aussi longtemps que je me souvienne et vous savez ce que ça fait? Cela rend l’installation de paquets moins pénible. Il n'est pas nécessaire d'entrer le mot de passe root toutes les 5 minutes, contrairement à ce que vous devez normalement faire. Vous ne rencontrez pas de problèmes pour essayer de sauvegarder/éditer des fichiers de configuration système, car ce ne sont que des autorisations root. C'est tellement plus facile et meilleur de fonctionner en tant que root.