Risque de sécurité dans l'utilisation quotidienne d'un compte administrateur (pas root)?


8

La seule chose qui distingue mon compte administrateur des comptes normaux est que mon compte administrateur est membre du sudogroupe et peut s'exécuter sudo. Est-il moins sûr d'utiliser mon compte administrateur pour le travail quotidien? Si oui, pourquoi?

Supposons que je suis très prudent lorsque j'entre mon mot de passe et que je sais ce qu'une commande fait avant de l'exécuter, bien sûr.

Si j'utilisais un compte non administrateur normal pour mon compte quotidien, lorsque je devais exécuter quelque chose en tant que root, je le ferais sudans mon compte administrateur (pas dans root, car il n'a pas de mot de passe et est désactivé!) Et y exécutez la sudocommande dans le shell administrateur; ou, je changerais les utilisateurs graphiquement. Ainsi, le nombre de commandes qui seraient exécutées est le même - l'utilisation d'un compte normal signifierait simplement que je dois entrer mon mot de passe administrateur deux fois lors de l'exécution de quelque chose en tant que root.

Les utilisateurs avancés devraient-ils donc travailler quotidiennement sur un compte normal au lieu d'un compte administrateur? Et pourquoi ou pourquoi pas?

Veuillez noter que par «compte administrateur», je veux dire un compte avec des privilèges à utiliser sudopour exécuter des commandes en tant que root - pas le compte root lui-même. Je ne me connecte jamais en tant que root.

Réponses:


5

Pas de risque sans root

D'après ma compréhension pour un administrateur ou un sudoutilisateur, cela fonctionne comme un utilisateur de bureau normal tant que nous ne le disons passudo - il ne devrait donc pas y avoir de risque supplémentaire.

Risque de devenir accidentellement racine

Il est également vrai qu'un utilisateur ayant potentiellement des autorisations d'administrateur doit surveiller de plus près où, quand et à qui il donne son mot de passe.

Je peux imaginer (bien que je n'en ai jamais rencontré) une mauvaise application ou un script vous demandant votre mot de passe sans vous dire pourquoi. Il effectuera probablement quelque chose avec les autorisations root, car il n'aurait pas besoin de votre mot de passe sinon. Si je ne sais pas ce que fait cette application, je ne lui donnerai tout simplement pas mon mot de passe root.

Nous sommes également responsables de rejeter à nouveau l'autorisation root après avoir terminé. C'est toujours une mauvaise idée de rester root tout en travaillant avec une application graphique comme par exemple Nautilus.

Risque de perdre l'accès root

Un autre "risque" peut être que vous faites quelque chose de mal avec votre compte qui vous empêche de vous connecter. Par conséquent, je crée toujours au moins deux utilisateurs administrateurs sur n'importe quelle boîte sur laquelle j'installe Ubuntu. C'est pour le cas où quelque chose casse mon compte principal.


La première réponse qui répond en fait à la question. Merci! Comme je l'ai dit, je (au moins supposons que je) fais attention où entrer mes mots de passe et quelles commandes exécuter. Mais je ne comprends pas pourquoi vous avez besoin de deux comptes d'administrateur alors qu'il y a encore le shell racine en mode de récupération?
Byte Commander

@ByteCommander Cela ne fonctionne que si vous avez un accès physique à l'ordinateur.
Jon Bentley

@JonBentley j'ai. Il s'agit de mon ordinateur personnel dans ce cas, cela signifie que je n'ai qu'un accès physique.
Byte Commander

Euh, NON. J'ai une attaque pour obtenir moi-même des privilèges sudo à partir d'un compte qui les utilise.
Joshua

10

Un compte qui peut sudo est techniquement aussi capable que le compte root (en supposant un sudoerscomportement de configuration par défaut ) mais il y a encore une grande différence entre root et un compte qui peutsudo :

  • Omettre accidentellement un seul caractère ne détruira pas Ubuntu. Probablement. Pensez à essayer de supprimer, ~/binmais en cours d'exécution rmcontre /bin. Si vous n'êtes pas root, il y a moins de risques.

  • sudonécessite un mot de passe, vous donnant ces millisecondes pour corriger les erreurs. Cela signifie également que d'autres applications n'ont pas la possibilité de faire des choses root en votre nom.

C'est pourquoi nous recommandons aux gens de ne pas utiliser le compte root pour le travail quotidien.


S'isoler avec un autre compte "admin" intermédiaire (et fonctionner en tant qu'utilisateur sans sudoaccès) n'est qu'une autre couche. Il devrait également s'agir probablement d'un mot de passe différent.

C'est encore plus simple et (selon les conditions de votre question) si quelque chose peut renifler votre premier mot de passe, ils peuvent probablement obtenir le second tout aussi facilement. Si vous n'avez jamais fait d'erreurs et n'utilisez jamais ces mots de passe forts ailleurs (non devinables ou fissurables), cette solution n'est probablement pas plus sécurisée. Si quelqu'un veut rooter, il démarrera la récupération, chrootera ou utilisera une clé .


Il existe également une école de pensée qui souligne que [pour les utilisateurs de bureau non professionnels], rien de ce que vous appréciez n'est protégé contre votre utilisateur . Tous vos documents, photos, historique de navigation web, etc est détenu et accessible par vous ou quelque chose en cours d' exécution comme vous. Tout comme vous pouvez exécuter quelque chose qui enregistre toutes vos frappes, affiche votre webcam, écoute sur votre microphone, etc.

Autrement dit, les logiciels malveillants n'ont pas besoin de root pour ruiner la vie de quelqu'un ou pour vous espionner.


1
Désolé, vous avez compris que ma question n'est pas tout à fait correcte. Je n'ai jamais envisagé de me connecter en tant que root. Mes options consistent simplement à me connecter en tant qu'administrateur ( sudoetc. membre du groupe) - - ou - - à me connecter en tant qu'utilisateur normal / restreint généralement et graphiquement ou dans un terminal en passant suà l'administrateur (en saisissant le mot de passe administrateur) puis en utilisant à sudopartir de là (en entrant mot de passe administrateur).
Byte Commander

Sur votre point concernant l'obtention du deuxième mot de passe tout aussi facilement, cela ne doit pas être le cas. Je gère mes machines de bureau avec Ansible, qui se connecte à un compte administrateur via ssh. Les comptes d'utilisateurs n'ont pas de privilèges sudo, et il n'est pas nécessaire d'utiliser un compte administrateur physiquement sur le bureau (en fait, ce n'est pas souhaitable, car je ne veux pas que mes machines soient gâchées individuellement et ne soient pas synchronisées avec le du repos).
Jon Bentley

@ByteCommander La seconde moitié de la réponse est basée sur ce que vous vouliez , mais les raisons de ce sont une extrapolation à partir de la racine-vs-admin arguments normal. C'est une autre couche de la même chose.
Oli

2

Oui, il y a des risques. Que ces risques soient ou non suffisamment importants pour que vous vous en souciez est une question de préférence et / ou de votre politique de sécurité.

Chaque fois que vous utilisez un ordinateur, vous êtes toujours menacé par des attaquants. Même si vous exécutez une configuration extrêmement sécurisée, vous ne pouvez pas vous protéger contre des vulnérabilités encore inconnues.

Si vous utilisez un compte sans privilèges sudo et que ce compte est compromis en raison de cette utilisation (par exemple, un enregistreur de frappe saisit votre mot de passe), cela ajoute une limitation des dommages qui peuvent être causés. Si un attaquant compromet un compte avec des privilèges sudo, il obtient également ces privilèges.

Sur la plupart des systèmes, l'utilisation de sudo entraînera la mémorisation de votre mot de passe pendant 15 minutes par défaut, ce qui constitue un autre facteur de risque, sauf si vous modifiez ce paramètre.


J'allais mentionner la mise en cache du droit à élever comme un risque potentiel : un script inconnu pourrait potentiellement contenir une commande sudo qui ne sera pas contestée, mais à moins que l'auteur ne soit modérément sûr que vous aurez émis une commande sudo récemment, dans Dans des circonstances normales, il demanderait le mot de passe, qui devrait être une alerte rouge indiquant que quelque chose d'étrange se produit.
TripeHound

@TripeHound Alternativement, vous vous éloignez de l'ordinateur pour une pause dans la salle de bain, après avoir autorisé une commande sudo, et quelqu'un d'autre intervient. Je ne vois pas de distinction entre les risques potentiels ou autres - le mot risque implique simplement qu'il y a une certaine probabilité non nulle d'un résultat indésirable. Oui, dans des circonstances normales, vous remarquerez la demande de mot de passe. Votre attaquant, qui a planté ce script sur 1000 ordinateurs et qui n'a pas de cible spécifique en tête, s'en soucie-t-il?
Jon Bentley

0

Ma réponse basée sur l'opinion, car tout devrait être prouvé mathématiquement, et je n'en ai aucune idée. ;)

Deux comptes, un avec des groupes admet sudo, signifie qu'un compte a le droit d'exécuter des commandes avec des sudodroits. Un sans ces privilèges.

  • Si vous avez déchiffré le mot de passe du compte non privilégié, vous devez toujours déchiffrer le mot de passe du compte privilégié maintenant. -> Avantage par rapport à un seul compte
  • Si vous avez craqué le compte privilégié. -> Aucun avantage par rapport à un seul compte

La probabilité est de 50% si vous ne respectez pas l'intelligence de l'attaquant.

De mon point de vue, c'est théoriquement un très petit avantage de sécurité et appartient davantage au domaine de la théorie des probabilités. Mais la perte de commodité augmente de façon disproportionnée. Cela dépend de l'intelligence de l'attaquant. Ne sous-estimez pas cette intelligence. C'est un faux sentiment de sécurité.

En d'autres termes, non, cela ne vous apporte aucun avantage mesurable, mais vous perdez beaucoup de confort. À la fin, chacun doit décider par lui-même.


0

Je cours exactement comme ça: un utilisateur où je fais mes trucs d'utilisateurs et un utilisateur où je ne fais que des trucs administratifs et pas de trucs d'utilisateurs. Même les invites de commande sont différentes: les utilisateurs ont une invite verte et les administrateurs une rouge!

Pourquoi?

L'utilisateur avait ses propres paramètres pour toutes les applications que j'utilise séparément de l'utilisateur administrateur, ce qui vous permet de:

  1. Déboguer si un problème est lié à l'utilisateur ou au système
  2. Ayez le compte administrateur en tant que compte utilisateur de sauvegarde au lieu du compte invité et du compte root si quelque chose va vraiment mal avec vos paramètres utilisateur et que vous ne pouvez plus vous connecter.
  3. conservez les documents administrateur et les documents utilisateur séparés dans leurs répertoires personnels respectifs si vous le souhaitez .
  4. Aucun effet lors de la frappe d'un accidentel sudoavant une commande.
  5. Aucun moyen de voir réellement ce qu'un utilisateur normal n'est pas censé voir.
  6. Aucun moyen de contourner un bogue d'escalade de privilèges utilisateur. (il y en a eu quelques-unes dans le passé)
  7. Soyez un "utilisateur normal" comme tous les autres utilisateurs de votre ordinateur et sachez quels sont les avantages / inconvénients.

D'accord, mais avoir des "documents administratifs" (que je n'ai pas vraiment) et des "documents utilisateur" séparés est un gros inconvénient à mon avis, car je veux toujours avoir toutes mes données en un seul endroit (plus les sauvegardes bien sûr). Idem pour les paramètres. Ils sont fondamentalement les mêmes, j'utilise même les mêmes profils Firefox / Thunderbird à partir d'un répertoire partagé. Et il existe d'autres comptes d'utilisateurs normaux d'autres membres de la famille, etc., je ne parle que des miens. J'attends avec impatience d'autres explications comme promis en (4.), mais vous ne m'avez pas encore vraiment convaincu, bien au contraire. : - /
Byte Commander

Été occupé avec RL. Il semble que vous ayez déjà une réponse acceptée, mais vous avez ajouté d'autres raisons, comme promis! ;-)
Fabby

1
Maintenant, ça vaut le coup! : D
Byte Commander
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.