Mis à jour de façon spectaculaire après 69 votes positifs, voir l'historique des réponses pour la réponse originale. Merci à @JimmyJames pour la discussion.
Parlons d'abord du modèle de menace :qu'essayez-vous d'empêcher l'agresseur potentiel de faire ?
Modèle de menace :usurpation d'identité/ransomeware sur un système mono-utilisateur
Généralement, pour les systèmes d'utilisateurs finaux, le de facto le modèle de menace est l'usurpation d'identité/le rançongiciel. Si l'attaquant a accès à vos documents et/ou peut exécuter des commandes shell à votre place, la partie est terminée. De ce point de vue, l'accès root ne rapporte rien à l'attaquant; ils peuvent obtenir ce qu'ils veulent sans cela.
Si l'usurpation d'identité/les logiciels malveillants sont la seule chose qui vous inquiète, il ne semble pas très important que votre utilisateur ait sudo pouvoirs, ou même si le navigateur s'exécute en tant que root.
(Je dois également souligner que les logiciels malveillants / vous connecter à un botnet peuvent se produire sans accès root puisque les scripts de connexion / planifier une tâche cron ne nécessitent pas root).
Randall Munroe de 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 selon laquelle "plus de sécurité, c'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, alors 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 vais quand même en discuter. Pour Linux, à cause d'un bogue (*ahem fonctionnalité*) dans le système de fenêtrage Xorg, votre compte de tous les jours ne devrait probablement pas avoir sudo pouvoirs. 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 à l'aide d'une simple commande shell utilisateur (non root). En résumé :
$ xinput list vous montre tous les appareils à saisie humaine connectés
$ xinput test <id> commence à faire écho à toutes les frappes sur l'appareil sélectionné.
J'ai testé et j'obtiens les journaux du mot de passe que je tape dans sudo dans une autre fenêtre de terminal. Si je verrouille mon ordinateur, lorsque je me reconnecte, je vois les journaux du mot de passe que j'ai tapé sur l'écran de verrouillage. Apparemment, ce n'est pas un bogue dans X, c'est une fonctionnalité. Bon, je vais aller me cacher sous mon lit maintenant.
Alors oui, cela soutient l'idée que tout utilisateur avec lequel vous vous connectez dans l'interface graphique ne devrait pas avoir sudo pouvoirs parce qu'il est trivial d'enregistrer votre mot de passe puis de devenir root. Je suppose que vous devriez avoir un compte dédié pour sudo et passer à un terminal TTY (ctrl+alt+# ) lorsque vous souhaitez utiliser sudo . C'est à vous de décider si cela vaut la peine de s'inquiéter ou non :personnellement, toutes les données qui m'intéressent sont déjà présentes dans mon compte d'utilisateur, mais je vais probablement modifier la configuration de mon ordinateur portable car 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 de résoudre (voir le point 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 de n'interagir qu'avec vos machines Linux via ssh, de ne jamais utiliser l'interface graphique.
Mac OSX
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 intervienne.
Windows
Je ne suis pas non plus un expert Windows, mais je pense que la fonctionnalité de contrôle de compte d'utilisateur (UAC) introduite dans Windows 7 a résolu ce problème en affichant les invites d'administration 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 su vers un autre compte et sudo pour obtenir des privilèges, c'est qu'avec sudo vous entrez le même mot de passe que celui 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 vous protégera de.
J'ai découvert qu'il était essentiel d'avoir deux comptes sur mes systèmes Unix pour la raison suivante :
Si jamais je gâche mon .bashrc ou d'autres fichiers de configuration de connexion / terminal, je peux me retrouver dans une situation où je ne peux même pas me connecter. Je suis donc totalement ennuyé. 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 être en mesure d'utiliser l'option de démarrage à partir d'USB mais pour être honnête, je trouve que pouvoir se connecter à un autre compte, utiliser sudo et réparer mon .bashrc puis se déconnecter et revenir dans l'autre compte peut être fait en quelques secondes avec la deuxième connexion et beaucoup moins effrayant / inconnu que l'option de démarrage USB pour réparer pour moi. Bien sûr YMMV (votre kilométrage peut très bien)