Question:
«Sudo» est-il presque inutile?
Wernight
2020-06-08 12:28:49 UTC
view on stackexchange narkive permalink

Une fois qu'un attaquant a un shell en tant qu'utilisateur sudoer (ou juste compromis un processus local suffisamment), il / elle peut utiliser l'un des nombreux outils d'escalade de privilèges pour même se mettre automatiquement par exemple en tant que apt ou un autre traitement appelé par root pour obtenir un accès root (voir aussi Que peut faire un attaquant dans ce scénario? (bashrc non inscriptible, profil, etc.)).

Quel est l'intérêt de sudo en dehors de bloquer les charges utiles plus petites ou de le rendre un peu plus difficile? Il semble que l'accent devrait être mis sur SELinux et autres.

Edit: Il y a 2 côtés de cette question (j'aurais dû être plus précis). Tout d'abord, ce que je voulais dire au départ, pour un utilisateur de bureau Linux standard. Une réponse assez différente pourrait être donnée pour une machine administrée par quelqu'un d'autre.

* "... il / elle peut utiliser l'un des nombreux outils d'escalade de privilèges ..." * - Vous semblez supposer que ce sont des outils génériques qui fonctionneront certainement sur le système cible.Mais ces outils reposent sur des bogues non résolus ou des erreurs de configuration.Ils ne fonctionneront pas sur un système correctement mis à jour et correctement configuré.Fondamentalement, vous demandez si sudo est inutile si tous les systèmes sont de toute façon cassés.Mais cette hypothèse de base est déjà fausse.
C'est beaucoup plus simple que vous ne le pensez si vous pouvez attendre un peu;voir l'exemple @reed's juste pour un et la question liée pour une protection naïve contre cela.Remarquant que pour les machines corp, un sudoers limité peut fournir une protection.
Bon point (et bonne réponse) mais cela suppose que l'utilisateur appelle `sudo` au lieu de` / usr / bin / sudo`.Certes, la plupart des utilisateurs le feront de cette façon.
Je voulais juste dire que je suis impressionné par le souffle des réponses ici.De sudo dans la plupart des valeurs par défaut de distribution (ma portée présumée initiale), à sudo power avec un compte administrateur séparé (local ou distant) (donc l'utilisateur standard a limité ou non sudo);et d'autres nombreuses situations décrites ici.
Pour ce que ça vaut, sudo peut être configuré pour accorder des autorisations beaucoup plus granulaires qu'un simple "accès root à tout".La plupart n'utilisent cependant pas cette fonctionnalité.
@Ajedi: La question des opérations devrait être "Est-ce que` sudo` est presque inutile lorsque les administrateurs paresseux déploient des configurations non sécurisées "
Dans votre montage, aviez-vous autre chose que "Firstly"?Je cherchais un "Secondly" ..
Vous n'avez qu'une demi-question ici.La vraie question est "Sudo" est-il presque inutile par rapport à quoi? ".`sudo` est certainement meilleur sur le plan de la sécurité que` su`, et l'un ou l'autre est bien meilleur que de se connecter en tant que `root` à tout moment.Avez-vous d'autres moyens de donner aux utilisateurs légitimes l'accès aux fonctionnalités d'administration tout en bloquant l'accès non autorisé, autre que `su` /` sudo` / root login, que vous pensez être meilleur que `sudo`?Sinon, c'est au moins la «moins inutile» de ces trois options.
Sans `sudo`, comment pourriez-vous amener quelqu'un à vous faire un sandwich?
@Wernight, il semble que vous (et de nombreux commentateurs) supposiez un système mono-utilisateur.En plus des autorisations granulaires, vous obtenez également un journal de qui a fait quoi.
Sudo était la première tentative du secteur de «sécuriser par défaut» pour les utilisateurs de console.(Tous les utilisateurs étaient «console», juste à un autre fil connecté à un multiplexeur série)
https://security.stackexchange.com/questions/187502/do-sudo-and-profile-bashrc-enable-trivial-privilege-escalation/187508#187508 vaut la peine d'être lu.
Onze réponses:
reed
2020-06-08 14:34:07 UTC
view on stackexchange narkive permalink

Sudo n'a aucun objectif de sécurité réel contre un tiers malveillant. Alors oui, c'est fondamentalement inutile à cette fin. Dans le passé, je pensais que c'était en fait un contrôle de sécurité pour empêcher l'escalade des privilèges et rendre les attaques plus difficiles, car certaines personnes continuent d'insister sur le fait qu'il a également cet objectif, mais c'est en fait faux. En fait, pour le moment, vous n'avez qu'une seule réponse à votre question, et cette réponse propage ce mythe. Le seul but de sudo est de vous protéger de vous-même, c'est-à-dire d'éviter de perturber votre système par erreur. Obtenir tous les privilèges en un seul clic ou en appuyant sur une touche peut être dangereux, tandis que sudo vous forcera au moins à taper consciemment votre mot de passe. Et si vous (ou un programme ou un script) finissez par toucher des fichiers système ou des fichiers d'autres utilisateurs par erreur, sans utiliser consciemment sudo , vous recevrez un avis "permission refusée". Donc en fin de compte c'est juste un outil d'administration, et pas en fait un contrôle de sécurité destiné à vous protéger d'une attaque.

Voici un exemple très basique de pourquoi sudo n'offre aucune protection réelle contre le code malveillant:

  # Create payload: remplacez sudo par un aliaspayload = 'fake_sudo () {# Simuler une invite sudo echo -n "[sudo] password for $ {USER}:" read -s mot de passe echo # Exécutez votre commande pour que vous soyez satisfait echo "$ password" | sudo -S "$ @" # Faites mes trucs diaboliques avec votre mot de passe echo "Terminé avec votre commande, maintenant je peux utiliser $ password pour faire ce que je veux"} alias sudo = fake_sudo '# Ecrire la charge utile dans le fichier de configuration bashrc " $ payload ">> ~ / .bashrc  

C'est un exemple très basique de code qu'un attaquant pourrait exécuter sur votre machine. Ce n'est pas parfait, il ne gère même pas tous les cas (cela ne fonctionnera pas bien si vous entrez le mauvais mot de passe), mais cela vous montre simplement que sudo peut être remplacé par un attaquant. Si vous exécutez ce script, la prochaine fois que vous ouvrirez votre terminal et exécuterez sudo , vous exécuterez en fait fake_sudo . Un attaquant peut remplacer vos programmes par des alias, ou remplacer les fichiers binaires (en plaçant des versions malveillantes dans ~ / bin ou partout où elles peuvent être exécutées dans votre chemin), etc.

Ceci n'est même pas une véritable "élévation de privilèges", car un utilisateur qui peut exécuter sudo pour devenir root a déjà tous les privilèges. Un véritable utilisateur non privilégié ne doit pas avoir les capacités sudo . Pour avoir une véritable séparation des privilèges, vous devez exécuter les tâches d'administration sur un compte totalement séparé.

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/109111/discussion-on-answer-by-reed-is-sudo-almost-useless).
Appeler les journaux `sudo` dans` / var / log / secure` ou `/ var / log / auth.log` selon votre système.Cela vous indique qui est le compte qui a gâché votre système ou qui est potentiellement compromis.Couplé à un fichier `sudoers` correctement configuré, un acteur malveillant ne peut pas supprimer ou modifier ces journaux.Si vous allez plus loin et autorisez uniquement les actions dans le fichier `sudoers` dont l'utilisateur a besoin et rien d'autre, la surface potentielle d'une attaque est très minime, même avec un` fake_sudo` comme démontré ci-dessus.
@SnakeDoc `sudo` peut le faire, mais la plupart des utilisateurs veulent` sudo` pour la tâche assez différente d'authentification pour administrer le système.De plus, du moins d'après mon expérience, ceux qui * pensent * utiliser «sudo» de cette façon ne le font généralement pas.Pour empêcher les utilisateurs de `sudo` de pouvoir effectuer une action (y compris la modification des journaux), ce n'est pas" un pas de plus "de limiter les utilisateurs à une petite liste blanche soigneusement organisée dans` sudoers`.Il est essentiel.De nombreuses commandes, peut-être la plupart, peuvent être utilisées pour augmenter les privilèges.En pratique, cela inclut toute commande qui accepte un nom de fichier de sortie comme argument (par exemple, `nmap`) et bien d'autres.
@EliahKagan Cela ne rend pas `sudo` inutile - cela rend beaucoup de systèmes mal configurés.Ne blâmez pas l'outil pour les erreurs de l'utilisateur.
Cela semble mettre sudo dans la même catégorie que ./executable
«Nous» n'a-t-il pas le même défaut?
@Rodney, fondamentalement, oui
Si vous donnez à l'utilisateur un accès root sans restriction, alors oui, cela n'aide pas contre un attaquant qui a détourné ce compte, mais vous pouvez configurer sudo beaucoup plus fin que cela.Avec des commandes fixes (si vous faites attention à l'environnement), vous pouvez autoriser les utilisateurs LOB à effectuer certaines actions privilégiées, et l'attaquant sera également limité à celles-ci.Un exemple typique serait de démarrer ou d'arrêter un démon / service pour une application d'entreprise (bien que systemctl puisse le faire avec policykit de nos jours)
Notez que l'exemple `fake_sudo` capture le mot de passe d'un compte utilisateur individuel _que vous avez déjà suffisamment compromis pour écrire dans son répertoire personnel_.Bien que définitivement mauvais, c'est toujours moins mauvais que les alternatives: les utilisateurs se connectent directement en tant que `root`, et vous avez compromis le répertoire de base _that_;ou les utilisateurs escaladent régulièrement avec `su`, et vous capturez le mot de passe root avec un` fake_su` similaire.Au moins de cette façon, l'administrateur système a des indices sur le compte qui a été compromis.
Selon cette logique, tous les logiciels de sécurité et contre-mesures n'ont jamais `` aucun objectif de sécurité réel contre un tiers malveillant '', car oui, dès que vous pouvez amener un utilisateur à exécuter un exécutable dans n'importe quel environnement, il y a très probablement un bogue ouun moyen sournois d'obtenir un accès root à partir de là. Le but est de rendre les choses plus difficiles.sudo protégera / ralentira de manière significative les attaques malveillantes dans presque toutes les situations, même dans votre propre exemple, il pourrait facilement s'écouler des semaines entre les invocations de sudo pour un utilisateur de bureau standard.
@user2979044, pas vraiment, car certains «contrôles de sécurité» sont en fait beaucoup plus difficiles à contourner, et nécessitent parfois des recherches sans jour ou continues sur les schémas anti-détection.Au lieu de cela, cette façon de «contourner» sudo est vraiment triviale, a toujours été triviale et continuera à l'être.Parce que ce n'est pas censé être un contrôle de sécurité aux fins que le PO demande.Notez que l'OP a en fait mentionné un scénario dans lequel l'attaquant peut exécuter du code, le bureau Linux typique et des problèmes liés à l'augmentation des privilèges.Je pense donc que ma réponse est appropriée.
Oui @reed, si un attaquant a déjà obtenu un accès complet au compte et au système, et la possibilité d'exécuter du code arbitraire, alors pwning le reste du système est trivial.Dans d'autres nouvelles, le ciel est bleu.
Bob Coggeshall
2020-06-10 03:26:25 UTC
view on stackexchange narkive permalink

Je suis le co-auteur de sudo. Il a été écrit au début des années 80 spécifiquement pour répondre au besoin de protéger l'intégrité d'une ressource partagée (un VAX-11/750 exécutant BSD UNIX) de ses utilisateurs (la faculté du département CS de SUNY / Buffalo). À l'époque, la seule autre option était «su» qui exigeait que tout le monde partage un seul mot de passe. Si une calamité s'était produite, il aurait été difficile, voire impossible, de passer au crible les analyses médico-légales et de déterminer qui était l'agresseur aux gros doigts ...

Je pense que l'utilité durable apparente de sudo est qu'elle rappelle à l'utilisateur de la ligne de commande que ils sont sur le point de faire quelque chose qui pourrait mériter une certaine certitude dans le résultat avant de taper. Certes, dans certaines implémentations, comme les principales distributions Raspberry Pi, où aucun mot de passe n'est demandé, il sert simplement de tampon. Alors allez comprendre.

Je crois toujours que les meilleures pratiques pour implémenter des applications sous des systèmes d'exploitation dérivés d'UNIX exigent que vous les exécutiez sous un ID non root. Si vous avez besoin de root, cela devrait être dans des circonstances contrôlées. Pensez à sudo comme à la manière dont l'accès root est accordé aux utilisateurs de ligne de commande dans des circonstances contrôlées. C'est tout.

Avez-vous un moyen de vérifier que vous êtes un co-auteur de sudo?Votre nom n'est pas mentionné sur https://www.sudo.ws/contributors.html
@Shadow https: // www.sudo.ws / contributors.html ne répertorie que les contributeurs depuis 1993, lorsque Todd C. Miller a commencé à maintenir sudo.La page que vous recherchez est https://www.sudo.ws/history.html, qui mentionne, * "Sudo a été conçu et mis en œuvre pour la première fois par Bob Coggeshall et Cliff Spencer vers 1980 au Département d'informatique de SUNY /Buffle."*
Il est encore utilisé à ce titre aujourd'hui.De nombreux clients d'entreprise associent sudo à la journalisation à distance pour conserver une piste d'audit de qui a fait quoi.Vous pouvez également faire su + auditd mais c'est un peu plus complexe.
Excellent, merci.J'espère que vous ne l'avez pas mal pris, mais sur Internet, il y a beaucoup de gens qui prétendent être des gens qu'ils ne sont pas.
C'est exactement pourquoi mon entreprise a fait en sorte que nos administrateurs utilisent «sudo».(Et changé le mot de passe root afin que 'su' ne puisse pas être utilisé pour l'accès root).Si quelque chose ne fonctionnait plus, il y avait des journaux sudo afin que nous puissions voir qui l'a fait et ce qu'il a fait.
@Shadow: "vous n'avez pas écrit sudo", Bob: "sudo i did", Shadow: "ok you did"
Excellent, merci Bob d'avoir répondu et d'avoir co-écrit sudo.Comme pour tout, il a ses avantages et ses inconvénients et c'est à nous de déterminer comment en faire bon usage de manière à avoir un impact positif sur la sécurité.
John Zhau
2020-06-08 12:51:38 UTC
view on stackexchange narkive permalink

Non, sudo n'est pas inutile.

En tant qu'utilisateur (cible)

Habituellement, lorsque vous sous Linux, vous agissez en tant qu'utilisateur non root. Beaucoup de choses, comme l'installation de packages avec apt , nécessitent l'autorisation root / sudo pour être utilisées. Le binaire sudo est là pour donner à l'utilisateur normal les autorisations d'utiliser des actions de niveau racine comme apt install .

Vous devriez ne pas utiliser Linux tout le temps en tant que root . En effet, si vous êtes compromis, l'attaquant aura un accès root à votre système, ce qui signifie qu'il peut faire à peu près n'importe quoi sur votre système. Au lieu de cela, vous exécutez Linux en tant qu'utilisateur non root, de sorte que même si votre compte est compromis, l'attaquant ne peut pas immédiatement obtenir l'accès root .

Bien sûr, aucun système est totalement sécurisé et quelque chose quelque part dans votre système peut être exploité. Utiliser un compte sudoers au lieu de root est une étape dans la sécurisation de votre système, comme indiqué ci-dessus.

Si vous dites "Le pirate va obtenir de toute façon, pourquoi devrais-je utiliser sudo ? ", c'est comme dire" Si quelqu'un entre chez moi, il pourra (d'une manière ou d'une autre) récupérer mes bijoux. Pourquoi devrais-je utiliser un coffre-fort ou des serrures? ". C'est une couche de protection supplémentaire. Nous ne cherchons pas "un verrou qui peut tout protéger" , mais "de nombreux verrous pour fournir une sécurité supplémentaire au cas où certains d'entre eux se casseraient" .

sudo est une sauvegarde. Il vous permet d'exécuter des programmes de niveau racine uniquement lorsque vous en avez besoin. C'est ainsi que vous n'ouvrez que parfois la porte de votre salle TOP SECRET au lieu de la laisser toujours ouverte, même si elle est toujours ouverte (toujours ouverte en tant que root) est plus pratique.

De plus, lorsque vous êtes un utilisateur légitime, vous n'exécutez pas de scripts d'escalade de privilèges chaque fois que vous souhaitez utiliser une action sudo , vous utilisez sudo.

En tant qu'attaquant

Le binaire sudo peut être exploité pour obtenir des informations ou même obtenir un accès root . Parfois, les utilisateurs peuvent avoir dans leur fichier sudoers quelque chose comme MY_USER ALL = (ALL) NOPASSWD: ALL , auquel cas, si vous pouvez accéder en tant que utilisateur MY_USER , vous pouvez exécuter toutes les commandes sudo / root sans mot de passe. L'exécution de sudo -l peut également vous donner des informations telles que les commandes que vous pouvez exécuter en tant que root même sans mot de passe. Un exemple d'une telle mauvaise configuration serait USERNAME ALL = (ALL) NOPASSWD: / bin / vi qui vous permet d'exécuter vi en tant que root sans mot de passe en tant qu'utilisateur NOM D'UTILISATEUR . C'est une manière d'augmenter manuellement les privilèges.

Chaque programme supplémentaire peut présenter des vulnérabilités supplémentaires. L'exécution de tomcat introduirait le système aux exploits de tomcat. sudo est peut-être juste un autre programme que vous pouvez utiliser dans votre exploitation.

De plus, comment pensez-vous que ces scripts / outils pratiques d'escalade de privilèges vous donnent un accès root? Beaucoup d'entre eux utilisent sudo d'une manière ou d'une autre.

Il est aujourd'hui très facile de gagner en root (@reed a donné un exemple simple).Il n'y a presque pas de coffre-fort à verrouiller.C'est juste dans une boîte facilement trouvable.
@Wernight étant donné l'exemple de reed, il est plus facile d'obtenir root si vous avez un accès utilisateur et que l'utilisateur vous le remet.Oui, bien sûr, si vous avez un accès de niveau utilisateur, il devient beaucoup plus facile d'obtenir le root Si vous incluez l'interaction avec l'utilisateur (et cet utilisateur se trouve juste pour vous donner son mot de passe root parce qu'il veut faire quelque chose qui l'exigeou ne se soucie pas que leur machine le demande soudainement).
Pedro
2020-06-08 20:36:33 UTC
view on stackexchange narkive permalink

Sudo est loin d'être inutile.

Un administrateur peut attribuer des privilèges de manière flexible et granulaire et avoir des options de responsabilité (journalisation décente). C'est une solution nettement meilleure pour l'utilisation de groupes.

Naturellement, si vous le comparez à SELinux , les performances et la capacité de sudo éclipsent, bien que de manière massive coût de mise en œuvre et de configuration (et de maintenance).

Inversement du point de vue d'un attaquant, il peut avoir de la chance et capturer un compte avec les privilèges sudo ou profiter de mauvaises configurations . Néanmoins, la quantité d'efforts pour passer d'un utilisateur standard avec les privilèges sudo à root pourrait être importante. D'un autre côté, aucun de ces problèmes n'est causé par sudo lui-même.

Cependant, son efficacité dépend entièrement de la configuration. Il est trivial de privesc un hôte si un compte standard compromis est autorisé à exécuter quoi que ce soit en tant que root sans mot de passe, c'est plus difficile mais tout à fait faisable s'il est autorisé à exécuter certaines commandes qui peuvent être manipulées et assez difficile si seuls des binaires et des situations soigneusement choisis sont autorisés à être exécutés en tant que root.

sudo peut également être utilisé pour activer les commandes en cours d'exécution comme les utilisateurs autres que root , c'est donc une autre façon d'utiliser sudo qui peut ne pas conduire à une compromission complète du système.

Je pense que l'escalade est extrêmement facile pour un utilisateur Linux standard.Je fais l'équivalent de `sudo apt update` tout le temps.L'administrateur est un bon point même si je ne pense pas que la plupart des utilisateurs de bureau installeraient la journalisation et qu'une fois qu'un attaquant a obtenu `root`, cette personne pourrait supprimer les journaux (mais c'est plus difficile, je suis d'accord).Je n'ai jamais mis cela en place jusqu'à présent.
Cela dépend entièrement de la configuration sudo.C'est trivial si l'utilisateur est autorisé à exécuter quoi que ce soit en tant que root, c'est plus difficile mais tout à fait faisable s'il est autorisé à exécuter certaines commandes qui peuvent être manipulées et assez difficile si seuls des binaires et des situations soigneusement choisis sont autorisés à être exécutés en tant que root.Sudo peut également être utilisé pour activer les commandes en cours d'exécution en tant qu'utilisateurs autres que root, c'est donc une autre façon d'utiliser sudo qui n'est pas une route directe vers root.
Même lorsqu'il est simple à exploiter, cela dépend de l'interaction de l'utilisateur avec le système (en tapant une commande `sudo` et en fournissant son mot de passe).Selon le système, cela peut être un obstacle important en soi, surtout si l'objectif de l'attaquant est sensible au temps.
Je pense que ce fil a de très bons points pour les administrateurs système qui maintiennent un parc ou une machine d'entreprise.Une telle configuration permet la journalisation et pourrait limiter les actions sudoer locales à des binaires spécifiques par exemple.Je ne suis pas convaincu que ce soit le cas pour la plupart des utilisateurs d'ordinateurs personnels (ou par défaut de distribution).Encore de très bons points dans le cas des entreprises.
@Wernight - Je ne peux pas parler à d'autres distributions, mais la configuration par défaut de Debian `sudo` inclut la journalisation dans` / var / log / auth.log`.Bien sûr, la question de savoir si l'utilisateur domestique moyen vérifiera un jour ces journaux est une toute autre question ...
Eliah Kagan
2020-06-09 00:50:39 UTC
view on stackexchange narkive permalink

sudo est aussi sûr, ou non, que ses alternatives populaires telles que su.

L'alternative la plus populaire à sudo est de permettre à certains ou à tous les utilisateurs d'élever leurs privilèges avec su . Le plus souvent, tous les utilisateurs sont autorisés à le faire, tant qu'ils connaissent le mot de passe de l'utilisateur cible . Contrairement à sudo , qui est presque toujours configuré pour exiger le mot de passe d'un utilisateur (et est limité uniquement aux utilisateurs de confiance), su nécessite le mot de passe de l'utilisateur cible .

Certaines personnes supposent que cela rend su plus sûr que sudo , mais ce n'est pas le cas. su est soumis aux mêmes types d'attaques que sudo . Supposons que vous soyez un utilisateur qui exécute parfois su pour devenir root. Supposons en outre qu'un attaquant qui ne connaît pas le mot de passe root et ne peut pas encore effectuer des actions en tant qu'utilisateur root parvient néanmoins à exécuter du code arbitraire en tant que compte non root. Tout comme cet attaquant peut faire en sorte que lorsque vous exécutez sudo vous exécutez sa commande malveillante, cet attaquant peut également faire en sorte que lorsque vous exécutez su vous ' exécutez leur commande malveillante.

Autrement dit, la technique de la réponse de reed fonctionne aussi bien pour introduire une fausse commande su qui capture le mot de passe de l'utilisateur cible (qui, lorsque su est utilisé pour administrer le système, est généralement root).

Mais il est possible de faire mieux que l'un ou l'autre, ou pour atténuer le risque.

Une fois que quelqu'un peut exécuter n'importe quelle commande comme vous, il peut généralement apporter des modifications arbitraires au comportement de votre shell, et ainsi créer de faux sudo , su , doas ou toute autre commande d'élévation de privilèges.

Cependant, tant que vous pouvez éviter d'interagir avec un faux écran de connexion , vous pouvez atténuer ce problème en ayant des comptes d'utilisateurs administratifs et non administratifs séparés. Cela ne semble pas être une nouvelle idée, et bien sûr que non, mais il est surprenant de constater à quel point cela est vraiment fait rarement.

Votre compte administratif pourrait soit juste le compte root. Mais si vous voulez les avantages de ne pas vous connecter en tant que root, qui incluent la journalisation (afin de déterminer ce qui n'a pas fonctionné en cas d'erreurs non malveillantes) et la possibilité d'exécuter des programmes qui ne sont pas censés fonctionner en tant que root (la plupart interfaces graphiques), alors vous pouvez avoir deux comptes non root, dont l'un est utilisé pour l'administration (dans lequel vous exécutez sudo ou su si nécessaire), et l'autre dont ce n'est pas le cas.

Ce compte devrait si bien sûr pas partager les identifiants d'accès avec le compte non administratif. Ils ne doivent pas avoir de mots de passe identiques ou similaires, et ils doivent avoir des paires de clés distinctes. De plus, vous ne devez pas passer du compte non administratif au compte administratif, pour la même raison, vous ne devez pas passer du compte non administratif à root.

Si vous faites cela, il y a même un argument pour sudo sur ses alternatives.

Dans cette configuration, il y a un avantage de sudo sur su , bien que ce ne soit pas un avantage décisif. Vous pouvez éviter d'utiliser accidentellement le mauvais compte - celui qui est utilisé pour toutes sortes d'autres choses non administratives qui peuvent l'exposer à un plus grand risque - pour administrer le système, en faisant en sorte qu'il ne s'agisse que d'un compte d'utilisateur limité régulier qui n'est pas répertorié et n'est membre d'aucun groupe répertorié dans le fichier / etc / sudoers .

Mais vous pouvez également atteindre cet objectif avec su soit en exerçant une autodiscipline appropriée et en vous assurant de ne jamais su -ing à partir du compte que vous avez conçu comme non-administratifs, ou en empêchant les comptes désignés comme non-administratifs d'élever des privilèges avec su . (Un moyen d'y parvenir, sur un système GNU / Linux, est avec AppArmor, qui est la façon dont Ubuntu a empêché le compte invité d'utiliser su avec succès - de retour dans les versions d'Ubuntu qui étaient livrées avec comptes invités activés.)

Le risque d'utiliser sudo ou su de la manière habituelle peut être acceptable pour vous.

Cela dit, je ne dis pas que vous devez nécessairement le faire. Cela dépend de vous ou, le cas échéant, de vous et des autres parties prenantes.

Pour de nombreuses personnes, les risques associés à l'utilisation du même compte en (a) passent à la racine avec sudo (ou des mécanismes similaires comme Polkit) ou su (ou des mécanismes similaires tels que doas ) comme il est utilisé pour (b) des tâches non administratives telles que l'exécution d'un navigateur Web peuvent être un compromis acceptable pour plus de commodité.

+1 pour enregistrer qui a fait quoi.C'est très pratique pour les analyses judiciaires ultérieures, même lorsqu'il est entièrement internalisé.
Jörg W Mittag
2020-06-10 15:44:02 UTC
view on stackexchange narkive permalink

Le point de sudo n'est pas de rendre difficile l'élévation des privilèges. C'est en fait exactement le contraire: il s'agit de faciliter facilement l'élévation des privilèges.

En facilitant l'élévation des privilèges lorsque vous en avez besoin , les utilisateurs sont moins incités à s'exécuter avec des privilèges élevés toujours.

Si vous rendez difficile l'élévation des privilèges, les utilisateurs se connecteront simplement en tant que root tout le temps. En facilitant l'élévation des privilèges «à la volée», les utilisateurs sont encouragés à se connecter en tant qu'utilisateurs non privilégiés et à n'élever les privilèges que pour un seul processus pendant la durée de ce processus, au lieu de s'exécuter avec des privilèges élevés en permanence. / p>

sudo est, fondamentalement, un outil d ' convivialité , pas un outil de sécurité. Les effets de sécurité de sudo sont des conséquences de second ordre des effets de convivialité. La sécurité n'est pas utile lorsqu'elle n'est pas utilisable.

En cela, sudo est à peu près équivalent à UAC dans Windows Vista +, qui est également souvent mal interprété comme un outil pour empêcher l'élévation de privilèges, alors qu'en fait c'est un outil pour faciliter l'élévation des privilèges. Avant l'introduction de l'UAC, il était tout à fait normal pour les utilisateurs de Windows de toujours se connecter à un compte avec des privilèges administratifs, simplement parce que pour tout autre chose que pour une utilisation bureautique de base, Windows était inutilisable autrement.

Il y a un avantage supplémentaire à sudo via su ou en vous connectant en tant que root , c'est-à-dire que sudo peut être configuré pour laisser une piste d'audit de quel utilisateur a émis quelle commande privilégiée à quel moment.

Cela résume bien la situation.
Tom
2020-06-09 17:00:07 UTC
view on stackexchange narkive permalink

Comme tout ce qui concerne la sécurité de l'information, sudo est un trade-off

Explorons les alternatives:

  • changer le système pour que le les commandes pour lesquelles vous utilisez sudo ne nécessitent pas de privilèges de niveau racine
  • connexion en tant que root pour obtenir les droits d'accès requis
  • en utilisant su pour passer à un shell root
  • ayant la commande elle-même exécutée en tant que root, peu importe qui l'exécute

sans entrer dans les détails, j'espère que vous conviendrez que toutes ces alternatives sont pires que sudo . Ce n'est pas parfait, il peut être attaqué - mais c'est la meilleure parmi ces alternatives.

Concernant SELinux, n'oubliez pas qu'il est entré dans la série relativement tard. Je ne me souviens plus en quelle année (et diable, j'étais là, mon nom est dans les informations d'identification SELinux), mais sudo précède considérablement SELinux.

Et tandis que SELinux est sans aucun doute l'alternative la plus puissante et la plus sécurisée, la plupart des administrateurs système ne sont pas capables d'écrire une politique de sécurité SELinux appropriée.

Donc, tout bien considéré, parmi un tas de mauvais choix, sudo est dans de nombreux cas le moins mauvais. C'est mieux que rien ou ses alternatives, et c'est une raison suffisante. Aucune sécurité n'est parfaite de toute façon.


Cela dit, l'utilisation principale de sudo dans l'entreprise n'est pas la sécurité mais la responsabilité . Si les administrateurs doivent se connecter avec un compte personnel, puis utiliser sudo pour leur travail quotidien, il est simple de savoir qui a fait quoi. Et en utilisant auditd, vous pouvez continuer à les suivre lorsqu'ils utilisent également su .

Martin Rosenau
2020-06-09 11:19:05 UTC
view on stackexchange narkive permalink

Cela dépend de la façon dont vous configurez sudo:

Sur une machine utilisée par différentes personnes, vous pouvez configurer sudo de manière à ce que certains utilisateurs peut accéder à certaines commandes en utilisant sudo:

Vous pouvez configurer sudo de manière à ce que certains utilisateurs puissent exécuter une certaine commande (par exemple ip ) en utilisant sudo - mais pas toute autre commande.

L'autre chose est que sudo doit être configuré comme on vous le demande pour un mot de passe. Même si un attaquant a accès à une console, il lui sera demandé votre mot de passe s'il tape sudo example command .

Vous pouvez également configurer sudo de telle sorte que certaines commandes (par exemple ip ) ne nécessitent pas de mot de passe et toutes les autres commandes nécessitent la saisie de votre mot de passe.

Et il est également possible de configurer sudo de telle sorte que le mot de passe requis pour sudo diffère de votre mot de passe de connexion.

Dans ce cas, même votre mot de passe de connexion n'aidera pas l'attaquant. .

Cependant, si vous configurez sudo de manière à pouvoir exécuter toutes les commandes et que vous ne serez pas invité à entrer un mot de passe, alors sudo le fera ne fournit aucune sécurité.

gmatht
2020-06-09 13:18:23 UTC
view on stackexchange narkive permalink

La plupart des choses sans clé d'attention sécurisée sont «presque inutiles».

Reed donne une excellente réponse pour expliquer pourquoi sudo (ou du moins sa fonction de mot de passe) est presque inutile pour la sécurité. Cependant, ce n'est pas seulement un bogue dans sudo , bash ou même dans tout l'environnement Unix. C'est un problème général avec l'obtention de privilèges plus élevés en utilisant un mot de passe sans aucune technique pour éviter les fausses invites de connexion.

Pour commencer avec zsh , fish et même l'invite de commande Windows vous permet de personnaliser la commande exécutée, donc le passage à un autre shell n'empêchera pas un attaquant de remplacer fake_sudo par sudo .

Ce n'est pas seulement l'environnement Unix. Imaginez dans Windows, par exemple, allez dans Démarrer> Changer de profil et saisissez le mot de passe administrateur. Opps, un attaquant a remplacé Explorer.exe par fake_Explorer.exe , ce n'était pas le vrai bouton Démarrer sur lequel vous avez appuyé. Encore une fois, l'attaquant a votre mot de passe administrateur.

À ces fins, une clé d'attention sécurisée est parfois utilisée. Vous avez peut-être parfois vu un écran de connexion Windows disant "Appuyez sur Ctrl-Alt-Suppr" pour vous connecter. En effet, Ctrl-Alt-Suppr va directement au système d'exploitation et ne peut pas être simulé par un faux shell de connexion. Parce que Ctrl-Alt-Suppr peut être utilisé pour attirer l'attention du système d'exploitation en toute sécurité, on l'appelle une clé d'attention sécurisée.

Il existe des alternatives à une clé d'attention sécurisée. Par exemple, vous pouvez choisir une image que vous espérez voir lorsque vous vous connectez. Mieux vaut ne pas stocker cette image là où des processus non privilégiés peuvent la lire ou l'afficher là où des processus non privilégiés peuvent la capturer. Cela nécessite donc toujours de séparer l'écran de connexion du compte de travail général non privilégié, comme le font des outils comme sudo .

étant donné que dans une entreprise, les administrateurs feront 99% de leur travail à distance, avoir une clé ou non ne fait aucune différence.
Je suppose, mais lorsque je travaille à distance, j'utiliserais une clé SSH pour l'authentification plutôt qu'un mot de passe sudo.J'ai précisé que je ne parle que de l'authentification par mot de passe.
Linux a déjà SAK (Secure Attention Key) comme Alt + SysRq + K (sauf si désactivé par votre distribution).Cependant, la * mise en œuvre * de cela est presque inutilisable pour une utilisation normale, c'est pourquoi elle n'est pas utilisée dans la pratique.De plus, `sudo` est souvent utilisé avec des hôtes distants et là, vous ne pouvez pas avoir SAK par définition.Lorsque vous accédez à un système distant, il s'agit de faire confiance au système distant avec toute entrée que vous fournissez;si vous entrez un mot de passe sur une entrée, le système doit être sûr.
just_floating
2020-06-10 01:04:18 UTC
view on stackexchange narkive permalink

J'ai eu le problème une fois de me connecter à mon serveur via des clés SSH et d'oublier mon mot de passe à utiliser avec sudo ce qui suggère cette idée:

Je suppose que s'il y a des compromis Les informations d'identification SSH, par exemple récupérées à partir d'un disque dur non essuyé dans une décharge, puis sudo peuvent aider car un mot de passe est nécessaire pour effectuer les fonctions d'administrateur. Je n'ai aucune preuve, mais je soupçonne que de nombreuses clés SSH n'ont pas de mot de passe.

Un vecteur d'attaque plus réaliste avec ce problème sudo sont les clés SSH laissées sur Github.

James Tocknell
2020-06-10 13:11:38 UTC
view on stackexchange narkive permalink

Quelque chose que non n'a pas mentionné jusqu'à présent, c'est que sudo (via PAM) peut utiliser d'autres mécanismes qu'un mot de passe et / ou utiliser l'authentification à 2 facteurs. Bien que cela ne résout pas le problème du compte compromis, cela rend plus difficile la falsification d'une invite.

De plus, sudo a ses utilisations à l'extérieur en donnant simplement un accès root complet, il peut être utilisé pour permettre à un utilisateur spécifique de exécutez une commande spécifique, et aucune autre en tant que root, ou même en tant qu'autre utilisateur. Je ne suis pas sûr que SELinux serait aussi facile à configurer pour ce cas d'utilisation.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...