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


192

J'ai souvent rencontré des publications sur des forums ou sur d'autres sites Web où l'on voyait des gens plaisanter de manière tellement générale sur le fait de se connecter / 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 la question.

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 à cause de cela.

Il existe en fait des distributions sur fond rouge vif avec des signes d’alarme comme fond d’écran 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.


15
Je pense qu'il n'y a pas de problème à exécuter un programme en tant que root. C'est juste que vous pourriez endommager le noyau de votre système d'exploitation (même les sudoers peuvent le faire) si vous n'êtes pas très sage sous Linux. à part ça, je pense qu'il n'y a pas de problème. Mais ce n'est que mon point de vue.
Gaurav Butola

1
Question connexe ici .
Loevborg

La difficulté d'entrer en mode racine varie d'une distribution à l'autre. Personnellement, je suis contrarié par le fait que Fedora ne vous permette pas de vous «lancer» immédiatement. Cependant, OpenSUSE et Ubunto ont une configuration sudo préconfigurée ... et donc, si vous choisissez la bonne distribution, vous pouvez minimiser vos ennuis de ne pas pouvoir accéder aux fichiers.
djangofan

4
@GauravButola Même si vous êtes un expert, c'est toujours une mauvaise idée au cas où une application serait compromise.
Strugee

2
@DaboRoss the OP indique qu'il travaille dans Windows en tant qu'administrateur; pour ma (petite) expérience dans ce système d’exploitation, il me semble que cela ressemble plus à Ubuntu: c’est un compte privilégié dans le sens où il peut faire tout ce que vous voulez, mais il demande la permission avant d’installer par exemple un nouveau logiciel. Donc, l'équivalent d'utiliser l'utilisateur "administrateur" dans Windows traduit en Ubuntu serait d'exécuter l'utilisateur principal avec sudo configuré de telle sorte qu'il ne demande pas le laissez-passer - l'exécution directe en tant que root est beaucoup plus dangereuse.
Rmano

Réponses:


154

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 /usrrépertoire à 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.


5
... et cela vous protège de la transformation d'erreurs insignifiantes lors de catastrophes. Je suis un utilisateur / adm Unix depuis 1990, mais je peux quand même sûrement glisser un espace au mauvais endroit rm -rf tmp/tests/*...
Rmano

9
1.) La plupart des gens considèrent que leur répertoire personnel est plus important que les répertoires racine, car ils ne peuvent pas être réinstallés. Donc je ne vois pas ce que tu veux dire. 2.) En termes de sécurité, vous avez raison. Mais venant de Windows (où il y a beaucoup plus de logiciels malveillants), où j'ai utilisé le compte administrateur depuis toujours (comme beaucoup le font), j'ai du mal à considérer cela comme un réel danger. Je suis trop paresseux pour taper sudomon mot de passe pour chaque seconde commande sous Linux. Les utilisateurs de Linux ne sont-ils pas supposés être paresseux ?????
phil294

pas d'accord -_-: ~: |
Edgy1

@LazyPower merci d'avoir modifié votre réponse, mais maintenant je ne la comprends plus. Pour modifier mon dossier privé Ubuntu ~, les programmes n'ont pas besoin de droits sudo. Rhythmbox PEUT effacer tout mon répertoire $ HOME / Music! Et c'est tout ce qui m'importe! Comment cela est-il lié aux autorisations root?
phil294

1
C'est un bon appel à Blauhirn. Je viens d'envoyer une modification de suivi pour indiquer que nous ne souhaitons pas supprimer l'ensemble de / usr. En termes de protection de vos dossiers $ HOME, rien de tel qu'une bonne sauvegarde ne peut vous aider. Je ne pense pas que ce scénario particulier serait autant lié à la sécurité qu’aux bonnes pratiques. Merci encore pour la légende.
lazyPower

79

Juste un mot: sécurité.

  1. Vous êtes connecté en tant qu'utilisateur root = toutes les applications fonctionnent avec des 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.
  2. Il ne s'agit pas uniquement de virus - un petit bogue dans une application pourrait effacer certains fichiers système ou ...
  3. 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 ...

16
Les fichiers de données, qui appartiennent tous à mon compte d'utilisateur, me sont beaucoup plus utiles que les fichiers système. Tous les exemples ci-dessus sont toujours d'actualité lorsque vous êtes connecté en tant qu'utilisateur, à l'exception du fait que les fichiers système facilement remplaçables sont sauvegardés.
kbeta

5
@kbeta vous supposez que vous travaillez sur un ordinateur où les seuls objets de valeur sont vos données et vos fichiers système. En réalité, Linux est souvent utilisé dans un système où de nombreux utilisateurs utilisent un système simultanément. Dans ce cas, la stabilité du système (et donc des fichiers système) est beaucoup plus précieuse et les autres fichiers utilisateur sont également importants.
Eric Pauley

2
@kbeta Assez, mais une configuration système endommagée peut également poser un risque pour vos données ... et bien sûr, des sauvegardes seraient une bonne idée de savoir si votre système est actuellement à risque ou non. Travailler avec une sauvegarde avec un plan de reprise après sinistre serait encore mieux.
Pryftan

47

Courir en tant que root est mauvais parce que:

  1. 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 nuisible, vous devez faire sudo, ce qui garantit quasiment une pause pendant que vous entrez le mot de passe, afin de vous rendre compte que vous êtes sur le point de réaliser un changement important / coûteux.
  2. Sécurité: Cela a déjà été mentionné à quelques reprises dans cette question, mais fondamentalement, 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.
  3. 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, une fois que sudo a expiré, il ne sudo -ivous reste plus qu'à vous installer en tant que root. Vous voulez exécuter des commandes à l'aide de pipes? Alors utilisez sudo sh -c "comand1 | command2".
  4. 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 :)) Ubuntu n'a pas de mot de passe Dans ce cas, le compte root peut être recherché en ligne mais vous pouvez effectuer une recherche en ligne, cela rendra la tâche plus difficile à quiconque ayant un accès physique à votre boîte de pouvoir faire du mal.

La raison pour laquelle vous n’avez pas pu trouver d’information sur les raisons pour lesquelles elle est mauvaise, 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 causé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 :).


'Une décennie peut-être?' Beaucoup plus long que cela même à partir du moment où vous avez écrit ceci. Même sans sudo, il convient de ne pas mentionner, par exemple, le groupe de roues (par exemple). La séparation des privilèges est toujours importante et a toujours été importante et le sera toujours. Beaucoup moins de personnes utilisaient un système d’exploitation sous Unix qu’il ya de nombreuses années et beaucoup d’entre elles sont habituées à être toujours administrateurs.
Pryftan

36

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 rootcompte. 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 par le biais de sudoses équivalents graphiques gksudoet kdesudo. Étant donné qu'il est facile de définir un rootmot de passe, pourquoi ne le fait-on 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 rootet 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 peuvent mal se comporter lorsqu'ils sont exécutés en tant que 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 reste raisonnablement par défaut sur un rootcompte inaccessible . D'une part, il existe une réelle différence entre l'accès à un compte d'utilisateur (avec des sudodroits) via une faille de sécurité et l'accès à l'accès root, car dans le premier cas, il sera nécessaire d'exécuter d'autres utilisateurs, ce qui demandera sudotoujours le mot de passe du compte. é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 de ne sudodemander que lorsque les privilèges de superutilisateur sont absolument nécessaires. Ainsi, lors de l’installation d’un programme à partir du source, il est conseillé de construire le source - en cours d’exécution configureetmake- dans le répertoire de l'utilisateur et en n'utilisant que sudo make installdans l'étape finale. 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 des scripts de construction fassent des ravages avec le système. Ainsi, même sur un serveur, il est conseillé de s'en tenir à l' administration basée sur sudo d'Ubuntu .


2
he will still be able to boot the system, even if the data will be lost.- Quel est le but de ceci? Si mes données sont perdues, mes données sont perdues et c'est tout. Le logiciel système Linux peut être réinstallé s'il est supprimé. Pourquoi devrais-je me soucier de la perte de données dans de tels répertoires? Par contre, la perte de données ~est mauvaise. Et sudone me protège pas de ça.
phil294

2
Une autre bonne pratique consiste à sauvegarder des données importantes. Si vous effacez le répertoire personnel, vous pouvez toujours démarrer et simplement copier des fichiers à partir de la sauvegarde. Ou, disons que vous avez un petit ordinateur portable pour voyager. Il y a peut-être des photos, des notes de voyage, des horaires de train, mais rien n’est trop crucial. Si vous effacez les fichiers utilisateur, vous pouvez toujours démarrer le système et enregistrer votre vol ou savoir quel bus emprunter.
Richlv

@ Blauhirn Backups. Et il y a une chance de récupération même si cela semble sombre.
Pryftan

34

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 serveurs, si un utilisateur est connecté en tant que root, vous ne savez pas qui est responsable des actions entreprises. Par conséquent, la plupart des organisations professionnelles dotées de plusieurs systèmes et de plusieurs administrateurs ayant besoin de rootprivilèges exigent que les utilisateurs se connectent à l'aide de leurs propres ID utilisateur (et mot de passe), puis utilisent sudodes programmes similaires pour utiliser des rootprivilèges lorsque cela est 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 utilisez rm -fr / home/me/my-subdirla racine, vous supprimez de manière spectaculaire tout ce qui est important de votre ordinateur à cause de l'espace après la première barre oblique. le /binet le /etcrépertoire. 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 root, 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(dans les coulisses). Des techniques similaires s'appliquent à Linux en général.

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


1
Il ne s'agit pas de blâmer quelqu'un, mais de savoir pourquoi quelqu'un a changé.
Jippie

2
@jippie: Je veux dire "blâmer" de la même manière qu'un VCS enregistre qui a fait quoi afin que la personne correcte se voit attribuer la responsabilité du changement, pour le meilleur ou pour le pire, et l'un des noms de la commande qui effectue ce suivi. est 'blâmer' Cela vous donne une personne à qui parler pour savoir pourquoi quelque chose est arrivé. Ce n'est pas toujours une "faute" (bien que très souvent déprimante, la raison pour laquelle il faut savoir est que quelque chose ne fonctionne pas tout à fait comme prévu et qu'il est nécessaire de savoir pourquoi pas). Il s’agit donc d’une question de responsabilité et de traçabilité plutôt que de reprocher à la personne ce qu’elle a faite.
Jonathan Leffler

Sur Ubuntu, des commandes telles rm -fr / home/me/my-subdirque ne tentent pas réellement de supprimer récursivement /, car elles /sont traitées spécialement pour se prémunir de telles erreurs. Voir la documentation des options --preserve-rootet --no-preserve-rootdans man rmpour plus de détails. Mais le principe est valable: il existe des fautes de frappe à un caractère qui rmsuppriment tout. Par exemple, si vous voulez supprimer tout le contenu du répertoire en cours en cours d'exécution rm -r *, mais que vous mettez accidentellement un /avant *, ce serait une mauvaise chose .
Eliah Kagan

@EliahKagan Mais si vous deviez le faire, chown -R nobody:nobody ../par exemple, cela vous protégerait-il? Si vous deviez le faire sous / etc, cela vous causerait beaucoup de tort. Il en va de même .*lors de l'exécution récursive d'une commande
Pryftan

21

TL; DR: Faites les choses en tant que root que lorsque vous devez. sudorend cela assez facile. Si vous activez les connexions à la racine, vous pouvez toujours suivre cette règle, il vous suffit de faire attention à le faire. Bien qu'activer correctement les connexions root ne soit pas réellement dangereux, vous n'avez pas besoin de l'activer, car vous l'avez sudo.

Il y a vraiment deux questions liées ici.

  • Pourquoi est-il mauvais de se connecter en tant que 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- sudoil 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 à:

  1. 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.
  2. Si vous exécutez un programme en tant que root lorsque vous n'en avez pas besoin et qu'il finit par faire quelque chose que vous ne vouliez pas faire - par exemple, en raison d'une vulnérabilité de sécurité ou d'un autre bogue - il pourrait changer ou être dommageable. votre système d'une manière que vous ne voulez 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 of=argument d'une ddcommande 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 augmenter vos risques et inclure de nouveaux moyens de 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, ce serait bien entendu un mauvais compromis. Mais cela ne le fait pas - chaque fois que vous souhaitez réellement effectuer une action en tant que root, vous pouvez le faire avec d' sudoautres 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; d'autres systèmes utilisent sudopar 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é au monde, est livré avec le compte root activé pour la connexion locale, basée sur un mot de passe.
  • RHEL , CentOS et Fedora font partie des autres systèmes d'exploitation respectés .
  • Debian (à partir duquel Ubuntu dérive ) demande à l'utilisateur de décider 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

  1. vous ne l'utilisez toujours que lorsque vous en avez vraiment besoin, et
  2. 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 ont besoin d'activer le compte root. En fait, cela n’est presque jamais nécessaire, alors il est important d’expliquer cela lorsque vous répondez à de telles questions. L'activation du compte root permet également de devenir facilement souple et d'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 en soi précaire.

sudoencourage et aide les utilisateurs à exécuter des commandes en tant que root uniquement lorsqu'ils en ont besoin. Pour exécuter une commande en tant que root, tapez sudoun 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 root car vous l'avez sudo. Mais tant que vous ne l'utilisez que pour les tâches administratives qui en ont besoin, l'activation et la connexion en tant que root sont à peu près sécurisées, à condition que ce soit uniquement de la manière suivante :

  • Localement, depuis une console virtuelle non graphique .
  • Avec la sucommande, 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:

  • Graphiquement. Lorsque vous vous connectez graphiquement, beaucoup de choses s'exécutent pour fournir l'interface graphique, et vous finirez par exécuter encore plus d'applications en tant qu'utilisateur root pour utiliser cette interface à n'importe quel 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 mentionne 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 de réaliser 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 utilisergksudo 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 rootcompte 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 sshou via d' autres mécanismes distants, ou même en configurant des services distants pour le permettre , vous facilitez l'accès des intrus, y compris les scripts automatisés et les programmes malveillants s'exécutant sur des réseaux de zombies, grâce à la force brute, aux 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 les connexions racine basées sur une clé , et non sur un mot de passe .

Par défaut, sous Ubuntu, ni les connexions racine graphiques ni les connexions distantes via SSH ne sont activées, même si vous activez la connexion en tant que racine . 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 utilisez un serveur ssh sur Ubuntu et n’avez pas changé /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 devraient 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:

  • Ne faites des choses en tant que root que lorsque vous en avez besoin; sudovous 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 également que vous n'avez presque certainement pas besoin d'activer le compte root .

Pour plus d'informations sur root et pour sudocertains avantages supplémentaires sudoque je n'ai pas abordés ici, je recommande vivement RootSudo dans le wiki d'aide d'Ubuntu.


'Si vous êtes la seule personne à utiliser votre ordinateur, les dommages que vous ne pouvez faire qu'en tant que root pourraient ne pas être plus importants que ceux que vous pouvez faire avec vos privilèges d'utilisateur habituel. Mais ce n’est toujours pas une raison pour augmenter votre risque »Sans parler du fait que cela vous met dans l’habitude de le faire ... alors vous passez à un autre système et que se passe-t-il? Idem avec l'idée absurde de familiariser les gens avec un rm -ipseudonyme de shell. Vous allez dans un système qui n'a pas cela et alors quoi? Garder un utilisateur assis dans des erreurs comme celle-là n'est jamais une bonne idée quand on considère que les humains sont vraiment des créatures d'habitude.
Pryftan

13

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). Sous XP, si la console de récupération est installée, toute personne qui a un accès physique à votre boîte peut démarrer (RC) - aucun mot de passe 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. Cela 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 toujours nécessaire d'accéder à la racine, le noyau Ubuntu a été modifié pour autoriser la connexion locale root uniquement en mode mono-utilisateur.

Voir aussi cette page


Hum Aucune infraction, mais vous voudrez peut-être lire le titre de la question, puis relire les détails.
Mussnoon

3
Cela est extrêmement utile - et il ne se rapporte à la question. Cela concerne les implications de l'activation du compte sur la sécurité, une condition préalable à l'exécution en tant que root.
Stefano Palazzo

1
@ Stefano Palazzo: Bien que les informations fournies puissent être utiles, je ne peux sincèrement pas voir dans quelle partie se trouve une réponse à ce que j'avais besoin de savoir. Je l'ai lu plusieurs fois.
Mussnoon

Cela n'empêche pas les gens de pouvoir se connecter à root.
Tchad

12

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

Je veux dire son tort parce que vous et vos applications auront plus de privilèges alors ils ont besoin et qui est quand les choses peuvent et parfois vont mal tourner :(


5
une analogie plus intelligente. (^_^)
kit.yang

2
C'est une analogie totalement inappropriée. Un enfant avec un AK47 peut se tuer et tuer d'autres personnes. Un utilisateur unix avec un accès root peut tout au plus rendre son système temporairement inutilisable. (On peut toujours ré-installer le système d'exploitation et récupérer l'opération).
kbeta

@kbeta Vous avez raison, mon analogie est un peu disproportionnée et exagérée. s'il vous plaît aller de l'avant.
Omeide

@kbeta l'analogie est appropriée. le risque n'est pas un système inutilisable, mais une perte de données et de confidentialité. l'utilisateur root peut supprimer les données. Veuillez utiliser votre fantasme pour associer la mise à mort et la perte de données.
n611x007

11

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 nouveau système 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 vous retrouver avec 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 un logiciel espion si elles 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 ...


"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." Peut-être que vous vous référez au répertoire lost + found? Si c'est le cas, vous pouvez en tant qu'administrateur spécifier le montant à réserver. Je veux dire que la valeur par défaut typique est 5% mais je peux me tromper et cela peut être changé. C'est très utile même si c'est rarement nécessaire. Apparemment, il y en a plus ici (je me souviens de mes années d'utilisation): unix.stackexchange.com/questions/18154/…
Pryftan le

Apparemment, cela ne se limite pas aux systèmes de fichiers ext: unix.stackexchange.com/questions/7950/…
Philip

Oui. Je le savais :) Mais merci d'avoir ajouté ça aussi.
Pryftan

10

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

  • La racine est toute puissante.
  • Dans les systèmes Unix et de type Unix, les privilèges d’administration de système sont tout ou rien. Un utilisateur a ou non un accès root, et l'accès root implique le contrôle complet d'une machine. Si la machine en question est utilisée par plusieurs personnes ou si root a accès à d'autres systèmes ou à des fichiers utilisateur, il est plus acceptable de donner à certains utilisateurs des privilèges root partiels.

  • L'utilisateur root peut masquer toutes ses actions.
  • sudo enregistre chaque commande exécutée via sudo. Avoir une trace de ce qui se fait avec sudo nous aide à diagnostiquer les problèmes liés aux systèmes / processus individuels et aux problèmes de configuration généraux, tout en nous aidant à identifier les améliorations nécessaires.

  • Le mot de passe root vous donne accès à toutes les commandes d'un système.
  • Sudo peut, via son fichier de configuration, donner à un utilisateur un accès root pour un ensemble de commandes particulier. Cela évite également l'effet "tout ou rien", ce qui nous permet de donner aux utilisateurs individuels davantage de contrôle sur leurs machines et de se sortir de problèmes courants.

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


    Mais quand vous avez plein sudo, vous pouvez sudo su et cacher vos actions.
    Wilhelm Erasmus

    8
    rm /*
    

    Disons que vous avez nettoyé une zone administrative. Vous en avez marre du mot de passe, alors vous sudo su. Vous êtes distrait juste pour la seconde et oubliez votre cd /. Alors toi rm *. Je l'ai fait. Vous pouvez tout récupérer, mais c'est un PITA. Oh, et c'est descendu /mediaaussi!


    10
    Nous nous plaignons toujours de la lenteur de nos PC, mais c'est comme s'ils étaient optimisés pour faire fonctionner une machine aussi rapidement.
    Jippie

    1
    @jippie Parce que RM détruit simplement le lien d'inode vers le fichier. Il ne faut pas longtemps pour supprimer un lien et marquer un espace comme "libre".
    Kaz Wolfe

    @jippie, il devrait y avoir une compilation en 10 secondes
    HopefullyHelpful

    7

    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 façon de faire "Ubuntu". Ubuntu a spécifiquement choisi de ne pas donner de nom d’utilisateur et de mot de passe root par défaut pour une raison quelconque. À la place, une installation par défaut d’Ubuntu sera utilisée sudo.

    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 sudosa commande. Par exemple, pour fonctionner en apt-get dist-upgradetant que superutilisateur, vous pouvez utiliser:

    sudo apt-get dist-upgrade
    

    Avantages de l'approche sudo

    • Avec sudo, vous choisissez à l'avance les utilisateurs qui ont un 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 avoir à changer le mot de passe root et à notifier un nouveau mot de passe à tout le monde.

    • Vous pouvez même choisir quelles commandes un utilisateur est autorisé à utiliser avec sudo et quelles commandes 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 un login root, vous restez en permanence dans un super-shell qui doit être quitté avec exitou logout. Cela peut amener les utilisateurs à rester dans le shell de superutilisateur 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 les privilèges de superutilisateur à la sucommande.

    Et de même, au lieu d’ su -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 limiter 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, attribuer à l'utilisateur root un mot de passe permettant les connexions en tant qu'utilisateur root, si vous souhaitez spécifiquement procéder ainsi à la place. Je voulais simplement vous informer de la convention d' sudoUbuntu consistant à préférer la préférence et essayer d'expliquer une partie des raisons pour lesquelles Ubuntu privilégie cette approche par défaut.

    Pourquoi ne pas autoriser la connexion root sur SSH?

    Même si votre utilisateur root dispose d'un mot de passe vous permettant de vous connecter en tant que root, il est néanmoins recommandé de désactiver la connexion directe à 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.

    • Il crée une meilleure piste de vérification de sorte que même en cas de violation où l'attaquant n'obtenir des privilèges de super - utilisateur plus tard, vous pouvez voir dont le compte utilisateur a été utilisé pour y accéder.


    6

    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.


    5

    C'est simplement trop facile de gâcher quand on fonctionne en tant que root. Vous pouvez écraser tout le système en une seule commande ...


    5

    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 aucune restriction. L’analogue correct de la racine dans Windows est Utilisateur système .

    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.


    3

    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.


    Bien que techniquement, il existe un moyen de consigner les actions, y compris chaque commande. Cela vaut pour chaque utilisateur. Voir la comptabilité des processus, par exemple ici: linuxjournal.com/article/6144 Et ce n’est vraiment sûr que si vous devez être root; sinon ce n'est pas entièrement sûr (exploit, etc.) même si la commande doit l'être.
    Pryftan

    3

    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 ne devrait pas être exécutée.)


    @StefanoPalazzo Cet article n'a aucun sens si la commande est supprimée. J'ai donc annulé votre modification. Vous pourriez aussi bien l'avoir supprimée. Notez que, contrairement aux idées reçues, cette commande, telle qu’elle est écrite, ne supprime pas les fichiers lorsqu’elle est exécutée sur un système Ubuntu, mais elle est similaire aux commandes qui le font. Donc, si vous craigniez que quelqu'un ne copie inconsciemment la commande et mette le système sur le système, il est peu probable. Voir la documentation des options --preserve-rootet --no-preserve-rootdans man rmpour plus de détails.
    Eliah Kagan

    Solaris considère cette commande comme un comportement indéfini selon une interprétation POSIX large (et par Bryan Cantrill) et renvoie une erreur.
    Jeremy Hajek

    3

    Avec un utilisateur averti et prudent, je ne suis pas sûr qu'il existe une bonne réponse. Je n'avais pas vu cette réponse, alors j'ai pensé y aller.

    Ce que je n'aime pas, ce sont les modifications non intentionnelles des autorisations sur les systèmes multi-utilisateurs que je dois chmodultérieurement. La fixation via chmod après coup est beaucoup plus irritante que le besoin de sudo, mais cela dépend de ce que j'ai prévu.


    3

    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, comme par exemple, gameret à 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 identifiant de connexion similaire kittyou gamersimilaire.


    2

    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 appelle une "réaction en chaîne" de multiples modifications, pas seulement là où vous en pensez probablement.
    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 une demande d'élévation des privilèges.


    1

    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 correcte des clés ssh pour tous les serveurs - et de fail2ban configuré pour toutes les connexions par mot de passe lorsque vous y êtes); 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: défaut ne rm -rf /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 à la flotte 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 les serveurs. (Ce qui est contourné par les gens qui le font dès que sudo su -possible après la connexion, laissant toutes vos intentions de journaliser ce qui s’est passé, même sans intentions malveillantes, dès lors que plus d’un utilisateur root est connecté. mesures 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 rétention, 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 afin que tous les serveurs soient corrigés régulièrement, vous serez probablement piraté un jour de toute façon, que ce soit de l'intérieur ou de l'extérieur.

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


    Enfin une réponse réelle et différenciée, au lieu de l’habitude de ne jamais faire ceci-mantras. +1 et merci pour cela.
    Andreas H.

    0

    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 n’éprouvez pas de problèmes à essayer de sauvegarder / éditer des fichiers de configuration système car ils Autorisations root uniquement. C'est tellement plus facile et meilleur de fonctionner en tant que root.

    En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
    Licensed under cc by-sa 3.0 with attribution required.