Le seul utilisateur d'un système * nix doit-il avoir deux comptes?
Le seul utilisateur d'un * nix (en particulier Linux et MacOS) devrait-il avoir deux comptes, un avec des privilèges Sudo et un sans? Il y a des années, j'ai lu que sur votre ordinateur personnel, vous devriez effectuer vos tâches quotidiennes en tant qu'utilisateur non privilégié et passer à un utilisateur privilégié pour les tâches d'administration. Est-ce vrai?
Remarque: je suis pas faisant référence à savoir si vous devez vous connecter en tant que root pour une utilisation quotidienne. C'est évidemment une mauvaise idée, mais votre compte d'utilisation quotidienne devrait-il pouvoir utiliser sudo?
Deuxième remarque: je fais spécifiquement référence aux appareils personnels qui sont pas utilisés comme serveurs ou pour héberger toute fonctionnalité pour les utilisateurs distants.
Mise à jour spectaculaire après 69 votes positifs, voir l'historique des réponses pour la réponse d'origine. Merci à @JimmyJames pour la discussion .
Tout d'abord, parlons du modèle de menace: qu'est-ce que vous essayez d'empêcher l'attaquant potentiel de faire?
Modèle de menace: vol d'identité/rançongiciel sur un système mono-utilisateur
Généralement pour les systèmes d'utilisateur final, le modèle de menace de facto est le vol d'identité/ransomware. Si l'attaquant a accès à vos documents et/ou peut exécuter des commandes Shell comme vous, c'est terminé. De ce point de vue, l'accès root ne gagne rien à l'attaquant; ils peuvent obtenir ce qu'ils veulent sans cela.
Si le vol d'identité/malware est la seule chose qui vous inquiète, il ne semble pas que cela ait beaucoup d'importance que votre utilisateur dispose des pouvoirs Sudo ou que le navigateur fonctionne en tant que root.
(Je dois également souligner que les logiciels malveillants/vous connecter à un botnet peuvent se produire sans accès root car les scripts de connexion/la planification d'un travail cron ne nécessitent pas de root).
Randall Munroe à XKCD semble être d'accord avec ce point de vue :
Enfin, j'ajouterai cette clause de non-responsabilité: Oui, je suis conscient que cela va à l'encontre de l'opinion publique générale selon laquelle "plus de sécurité est toujours mieux". Ce n'est tout simplement pas vrai. Parfois, plus de sécurité est pire, comme des politiques de mot de passe trop complexes qui finissent par forcer les gens à écrire leurs mots de passe. Vous devez toujours examiner les risques et décider du niveau de sécurité réellement approprié. Dans ce cas, il n'y a pas de mal à verrouiller l'accès root, mais vous vous compliquez la vie et il n'est pas clair que vous en tiriez quelque chose.
Modèle de menace: accès root ou système multi-utilisateur
Si vous avez un modèle de menace où l'attaquant veut quelque chose auquel seul root a accès, ou s'il y a plus d'un compte utilisateur sur la machine, la réponse dépend en fait du * nix dont vous parlez. Cela s'éloigne rapidement des boîtiers d'ordinateurs personnels et des boîtiers de serveurs, mais je discuterai quand même. Pour Linux, en raison d'un bogue (* ahem feature *) dans le système de fenêtrage Xorg, votre compte quotidien ne devrait probablement pas avoir les pouvoirs Sudo. Pour les systèmes d'exploitation qui n'utilisent pas X, c'est probablement correct.
Linux (exécutant le système de fenêtres X.org)
Voici un excellent article qui vous montre comment enregistrer toutes les frappes sur une machine gui linux en utilisant une commande Shell simple utilisateur-land (non root). En résumé:
$ xinput list vous montre tous les périphériques d'entrée humaine connectés
$ xinput test <id> commence à faire écho à toutes les frappes sur le périphérique sélectionné.
J'ai testé et j'obtiens des journaux du mot de passe que je tape dans Sudo dans une fenêtre de terminal différente. Si je verrouille mon ordinateur, lorsque je me reconnecte, je vois les journaux du mot de passe que j'ai tapé dans l'écran de verrouillage. Apparemment, ce n'est pas un bug dans X, c'est une fonctionnalité. Bon, je vais me cacher sous mon lit maintenant.
Donc oui, cela soutient l'idée que tout utilisateur avec lequel vous vous connectez dans l'interface graphique ne devrait pas avoir les pouvoirs Sudo car il est trivial de connecter votre mot de passe et de devenir root. Je suppose que vous devriez avoir un compte dédié pour Sudo ing et passer à un terminal TTY (ctrl+alt+#) lorsque vous souhaitez utiliser Sudo. C'est à vous de décider si cela vaut la peine ou non: personnellement, toutes les données dont je me soucie sont déjà présentes dans mon compte d'utilisateur, mais je vais probablement changer la configuration de mon ordinateur portable parce que je suis un nerd de la sécurité.
Notez que lors de mes tests, je n'ai pas pu enregistrer de clé entre les utilisateurs. Faire "Changer de compte" dans l'interface graphique, ou startx dans un nouveau terminal tty semble lancer une instance isolée de X.
Merci à @ MichaelKjörling pour cette observation:
C'est l'une des choses que Wayland [système de fenêtrage conçu pour remplacer X] essaie en fait de corriger (voir la puce sur la sécurité ). N'oubliez pas que X11 est né à une époque où le modèle de menace était très différent de ce qu'il est aujourd'hui.
Pour les administrateurs système : cela renforce l'habitude d'interagir uniquement avec vos boîtes Linux sur ssh, n'utilisez jamais l'interface graphique.
Mac OS X
Je ne suis pas un expert OSX, mais je sais qu'il n'utilise pas le serveur Xorg, donc je suppose que l'interface graphique d'Apple gère cela correctement, mais j'aimerais que quelqu'un de plus expert que moi puisse peser.
Les fenêtres
Je ne suis pas non plus un expert de Windows, mais je pense que la fonctionnalité Contrôle de compte d'utilisateur (UAC) introduite dans Windows 7 a résolu ce problème en faisant en sorte que les invites d'administration s'affichent dans un bureau sécurisé dont les bus d'entrée sont isolés de votre bureau habituel.
Dans la plupart des situations, exiger un mot de passe avec Sudo est une protection suffisante.
La principale différence entre suing vers un autre compte et Sudoing pour obtenir des privilèges est qu'avec Sudo vous entrez le même mot de passe que vous avez utilisé pour vous connecter. Si votre modèle de menace suppose qu'un attaquant a le mot de passe de votre compte , alors vous avez déjà de gros problèmes, plus qu'un autre mot de passe sur le compte root ne vous protégera.
J'ai constaté qu'avoir deux comptes sur mes systèmes Unix est essentiel pour la raison suivante:
Si jamais je gâche mon .bashrc ou d'autres fichiers de configuration de connexion/terminal, je peux entrer dans une situation où je ne peux même pas me connecter. Donc, je suis totalement borked. C'est la pire situation imaginable car vous ne pouvez pas faire grand-chose si vous ne pouvez pas vous connecter.
La seule façon dont j'ai pu résoudre ce problème sur quelques ordinateurs était d'avoir l'autre connexion qui me permet d'entrer et d'utiliser Sudo, de réparer les fichiers de démarrage de mon compte principal. Je me déconnecte ensuite de mon compte'2 'et me reconnecte à mon compte habituel.
Parfois, je pourrais pouvoir utiliser l'option de démarrage à partir d'USB, mais pour être honnête, je trouve que je peux me connecter à un autre compte, utiliser Sudo et corriger mon .bashrc puis me déconnecter et me reconnecter à l'autre compte peut tout être fait en quelques secondes avec la deuxième connexion et beaucoup moins effrayant/inconnu que le démarrage USB pour réparer l'option pour moi. Bien sûr YMMV (votre kilométrage peut très)
J'utilise cette configuration, mais la raison va au-delà d'un seul système.
Si vous voulez des sauvegardes qui fournissent des protections contre les ransomewares (et que vous n'aimez pas supposer que personne n'écrira de ransomewares pour Linux), vous devez sauvegarder sur un système externe qui conserve plusieurs révisions.
Cependant, je n'ai pas de poste de travail/terminal dédié pour l'administration du serveur de sauvegarde. La connexion en tant qu'utilisateur distinct pour cela (sans utiliser su) fournit ici une couche de protection. Si ma connexion normale avait les privilèges Sudo, il y aurait toujours un ralentissement, mais il serait assez mince (obscurité et les logiciels malveillants devraient capturer le mot de passe Sudo).
Chaque machine a besoin d'un compte administrateur, quel que soit le système d'exploitation. Ok, la plupart des saveurs Linux cacher utilisateur root en lui donnant un mot de passe inexistant - dans le sens où toute entrée retournera false - mais root existe et a l'ID utilisateur 0.
Ce compte administrateur peut modifier n'importe quoi dans le système, y compris les choses qui ne sont pas autorisées pour les utilisateurs normaux. La ligne de défense ici, c'est que si un attaquant accède à l'utilisateur root par hasard (*) il peut facilement installer une porte dérobée pour pouvoir la récupérer à volonté. Et vous ne le remarquerez guère que si vous analysez régulièrement la sécurité de vos systèmes (journaux, modifications des fichiers système, ...) sur une base régulière.
Si un attaquant accède à un compte non root par hasard, il ne pourra apporter des modifications qu'à ce qui est accessible à ce compte. Ok, il pourrait changer le mot de passe s'il réussit à obtenir un Shell, mais vous le remarquerez certainement la prochaine fois que vous essayez de vous connecter!
Cela signifie que la ligne de défense de ne pas utiliser root est uniquement contre les attaques à distance - si quelqu'un a un accès physique à une machine, il peut lire tout ce qui n'est pas fortement crypté et écrire/effacer absolument tout - y compris la base de données de mots de passe pour ajouter d'autres comptes d'administrateur . La seule exception ici est que si tout le disque est crypté, la seule action possible est de tout effacer et de la réinstaller.
Mais j'avoue que même si je sais que Sudo est un excellent logiciel et peut être utilisé pour permettre une autorisation fine. Je n'aime pas beaucoup la manière Linux par défaut où Sudo peut tout faire, car elle est vulnérable à ceci:
- un attaquant accède à un Shell non root autorisé à Sudo
- il change le mot de passe du compte
- il démarre en tant que root et installe une porte dérobée (ou une version modifiée de su qui ne demande pas de mot de passe - triviale à écrire)
- il casse le fichier de mot de passe principal et s'en va
La prochaine fois que vous essayez de vous connecter, vous remarquerez que vous ne pouvez pas, utilisez la procédure de récupération pour découvrir que le mot de passe principal est cassé, reconstruisez-le ou réinstallez-le à partir d'une version archivée et si vous n'analysez pas soigneusement le système, ne remarquez jamais la porte de derrière.
Quand j'ai dit accéder par hasard, je veux dire d'une manière non reproductible, par exemple, s'il utilise une vulnérabilité lorsque vous vous connectez à un site malveillant. À moins que l'attaquant n'installe une porte dérobée, il ne pourra y accéder à nouveau que lorsque vous reviendrez sur ce site, ce qui peut ou non se produire.
TL/DR: Mon opinion est que toute machine doit avoir au moins 2 comptes: un non privilégié pour une utilisation normale, et un administratif pour les tâches administratives.
Quels sont les avantages de Sudo?
Vous n'avez pas besoin de partager le mot de passe root avec chaque utilisateur pour effectuer certains types de tâches administratives sur votre propre système.
L'authentification expire automatiquement après un court instant (15 min) et vous pouvez définir timestamp_timeout=0 en dessous de /etc/sudoers pour faire expirer le mot de passe Sudo toutes les 0 (zéro) secondes. Cela signifie que chaque fois que vous utilisez Sudo, le mot de passe vous sera demandé.
Quels sont les inconvénients de Sudo:
Lorsqu'un utilisateur utilise un mot de passe faible, il permet à un attaquant de casser rapidement le mot de passe de l'utilisateur et d'élever le privilège d'obtenir l'accès root
Le mot de passe root peut être verrouillé par défaut dans certaines distributions Linux comme Ubuntu. Pourquoi?
Parce qu'en présence du compte root, un attaquant tentera pour la première fois de forcer brutalement le mot de passe root. Ce sera plus compliqué si le compte root est désactivé.
Un utilisateur peut changer la propriété des fichiers système en connaissant le mot de passe root ou en endommageant votre système en exécutant un programme malveillant.
Tous les utilisateurs de PC doivent avoir au moins un administrateur local, mais le bon sens veut que cela soit protégé par mot de passe (les utilisateurs d'Android le notent). Selon l'utilisation, je ne vois aucune raison pour laquelle il ne peut y avoir qu'un seul compte. C'est le cas pour Puppy Linux et a connu un certain succès depuis des années. Cependant, il est bon d'avoir deux niveaux de protection et un dossier/sbin séparé pour les moments où nous sommes maladroits et/ou stupides. C'est une chose que de composer un numéro, c'est une autre de supprimer des répertoires. Les utilisateurs paresseux ajouteront simplement tout ce dont ils ont besoin au fichier sudoers. L'escalade de privilèges repose généralement sur l'accès à un compte en premier lieu, nous contrôlons donc cela. Les comptes sur les serveurs et les appareils doivent être justifiés, et nous nous soucions de l'utilisation de notre poste de travail comme un appareil de facto contre nous. Le fait est que, pour de nombreux PC, il y a non autre utilisateur réel.