Quand Ubuntu demande le mot de passe d'un utilisateur administrateur, comment décide-t-il quel utilisateur administratif demander?

Question

Je suis en train de configurer une machine Ubuntu (10.10) qui sera utilisée par plusieurs personnes. C'est une machine partagée dans un petit bureau. Ses rôles principaux sont l'hébergement de machines virtuelles avec VirtualBox et le traitement de fichiers avec Samba.

Pour Samba, plusieurs comptes utilisateur doivent être configurés pour que différentes personnes puissent se connecter aux partages Samba à partir de leurs propres postes de travail. Cependant, il existe également un compte dédié à l'exécution de machines virtuelles que plusieurs personnes utiliseront. Parfois, certaines personnes essaient d'utiliser ce compte avec des privilèges élevés, ce qui entraîne l'affichage de la boîte de dialogue "Veuillez saisir le mot de passe d'un utilisateur administratif" de Gnome. Cependant, cette boîte de dialogue demande mon mot de passe. Lorsque j'ai configuré la machine, le premier compte a été créé pour le mien. Cela semble donc supposer que je suis le seul utilisateur à avoir reçu les pouvoirs de Sudo.

Je veux désigner un autre utilisateur comme "administrateur de premier recours", pour ainsi dire, et il ne peut s'agir d'un utilisateur de compte partagé, car tout le monde doit connaître le mot de passe de ce compte. Je souhaite donc que ses privilèges soient strictement limités. Il ne peut s'agir de mon compte, car je ne dis pas grand-chose à mon mot de passe, et je ne serai pas présent sur le site assez souvent pour le saisir moi-même. Il y a cependant quelqu'un qui peut le fait en personne, alors je les ai ajoutés à /etc/sudoers. Comment puis-je dire à Ubuntu que lorsqu'il lui faut élever des privilèges pour quelque chose, il devrait d'abord demander leur compte?

Résumer:

Comptes sur la machine: Alice, Bob, Carol, Dave, Eliza.
Lors de l'installation d'Ubuntu, Alice était le premier utilisateur ajouté au cours du processus d'installation.
"Dave" est en fait un compte que beaucoup de gens utilisent, qui ne peuvent pas être dans /etc/sudoers parce que son mot de passe est de notoriété publique.
Bob a été défini pour être un compte "administratif" dans Gnome et est correctement entré dans /etc/sudoers - Bob est le patron de ce bureau.
Lorsque des actions nécessitant des privilèges élevés sont tentées alors que vous êtes connecté en tant que Bob, Carol, Eliza ou Dave, le système doit demander les informations d'identification de Bob.
Lorsque des actions nécessitant des privilèges élevés sont tentées alors que vous êtes connecté en tant qu'Alice, le système doit demander les informations d'identification d'Alice (bien qu'Alice soit en quelque sorte un administrateur système et ait l'habitude d'utiliser su - pour effectuer des tâches d'administration étendues).

Quels changements de configuration dois-je apporter pour obtenir l'état souhaité ici?

enzotib · Accepted Answer

Tout d'abord, signalons que les actions privilégiées sont autorisées pour un utilisateur non root via deux mécanismes différents.

Sudo
PolicyKit

Le premier est utilisé lorsque vous exécutez explicitement une commande avec Sudo ou un élément de menu dont la commande est entourée de gksu (comme Gestionnaire de paquets Synaptic).
Dans ce cas, le mot de passe requis est celui de l'utilisateur qui appelle, généralement celui qui s'est connecté.

Le second est utilisé lorsqu'une application compatible avec PolicyKit tente d'effectuer une action privilégiée. Dans un tel cas, l'application demande à l'autorité locale du PolicyKit (via D-Bus) si l'action peut être exécutée. L'autorité locale demande ensuite à l'utilisateur actif, par l'intermédiaire d'un agent d'authentification, de prouver son identité. La fenêtre de dialogue ressemble à la suivante (malheureusement avec du texte en italien :)

enter image description here

Vous pouvez identifier PolicyKit à partir du petit triangle noir et de l'étiquette Détails. Comme vous pouvez le constater, si plusieurs utilisateurs font partie du groupe admin, vous pouvez choisir dans la liste l'utilisateur à utiliser pour l'authentification.

Compte tenu de tout cela, Sudo et PolicyKit sont beaucoup plus compliqués en ce qui concerne les configurations possibles: vous pouvez configurer une action pouvant être exécutée sans mot de passe, exécutée uniquement par un utilisateur ou un groupe particulier, etc.

Pour répondre à votre question, lorsque le mécanisme utilisé par l’application est PolicyKit, indépendamment de l’utilisateur actuellement connecté, le mot de passe requis serait celui de Bob ou Alice (les deux seuls utilisateurs admin, si j’ai bien compris), et vous pouvez le modifier. dans la liste, l'utilisateur que vous souhaitez utiliser pour l'authentification.

Lorsque le mécanisme utilisé par l'application est Sudo (pour les tâches d'administration exécutées via l'interface graphique, cela devient moins fréquent), vous n'avez aucun moyen simple et immédiat de choisir l'utilisateur pour l'authentification.

0xC0000022L · Answer

Clairement, Sudo serait le premier choix pour moi dans un tel cas. Le principal problème semble être que la plupart des administrateurs (actuels) n'utilisent pas réellement /etc/sudoers dans toute la mesure du possible (User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

La plupart des administrateurs finissent par n’utiliser que certaines des règles existantes et d’ajouter des utilisateurs, voire pire, d’ajouter des utilisateurs au groupe Sudo pour lequel une règle existe généralement dans les installations Ubuntu (%Sudo ...). Ceci, bien sûr, donne aux utilisateurs respectifs le libre règne et la pleine puissance du compte superutilisateur.

Compte tenu de votre commentaire:

alors je les ai ajoutés à /etc/sudoers

Je pense que vous ne l'utilisez pas dans la mesure du possible.

Dans un scénario comme le vôtre, je rédigerais littéralement les quelques actions auxquelles Bob doit être limité. En fait, c’est ce que j’ai fait sur un serveur que je maintiens, pour permettre à deux utilisateurs particuliers de redémarrer un invité KVM particulier sur un hôte. Les scripts contiendraient un hashbang avec un chemin absolu vers l'interpréteur (par exemple, #!/bin/dash au lieu de #!/usr/bin/env bash) et s'exécuteraient probablement avec un shell utilisé ailleurs pour des tâches privilégiées (/bin/dash ou /bin/sh). Ce ne sont que des précautions. En dehors de cela, je m'assurerais de coder en dur tous les chemins absolus vers les fichiers binaires et d'en utiliser le moins possible. Par exemple. lorsque vous utilisez bash/dash, je préférerais builtins à commands (voir man bash). Vous pouvez rendre ceci maintenable en assignant à une variable le chemin absolu et en faisant référence au programme basé sur cette variable ($VIRSH au lieu de /usr/bin/virsh). Si vous le pouvez, vérifiez le code des scripts externes avant de les appeler. Surtout si vous devez les appeler dans un contexte privilégié. Dans mon cas, je limite également les utilisateurs à un répertoire racine particulier et à un sous-système SSH particulier, car ils se connectent uniquement à la machine via sshd et à l'authentification par clé publique. De toute évidence, vous n'en avez pas besoin.

Assurez-vous de chown root: <the-script>; chmod u=rw,a=,a+rx <the-script> pour empêcher quiconque mais root correct de le bricoler. Faites également attention avec les bits setuid et setgid activés sur les fichiers binaires cibles (vous pouvez utiliser find pour les repérer). Supposons pour le moment que votre script réside dans /usr/sbin/priv-action.

Maintenant, éditez votre /etc/sudoers. noexec peut être utilisé pour empêcher d'autres fichiers binaires que ceux explicitement autorisés. Il existe en fait de nombreux paramètres supplémentaires, pas seulement ceux que je décris ici. Assurez-vous donc de consulter man sudoers.

Maintenant, je préfère nommer les utilisateurs (User_Alias) dans mon fichier sudoers, mais vous pouvez également utiliser un Group_Alias (man sudoers) ou un groupe de systèmes réel (par exemple %Sudo):

# The list is comma-separated: bob,alice,... User_Alias LIMITED_ADMINS=bob

puis ajoutez un alias de commande pour permettre l'exécution de ce script particulier:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,... Cmnd_Alias PRIV_ACTION=/usr/sbin/priv-action

Enfin et surtout, la ligne magique permet à bob (ou plutôt aux utilisateurs répertoriés sous LIMITED_ADMINS) d'exécuter les commandes privilégiées via le script:

LIMITED_ADMINS ALL=(root) PRIV_ACTION

Contrairement aux définitions d'alias précédentes, cette ligne nécessite une explication. Alors, commençons par creuser dans les parties sur une moyenne de la ligne "Spécification de l'utilisateur". Ici man sudoers aide:

La structure de base d'une spécification utilisateur est who where = (as_whom) what.

Exemple de ligne (trouvée sur la plupart des configurations Ubuntu):

root ALL=(ALL) ALL

Cela signifie qu'un utilisateur nommé root (utilisez #0 pour le lier à l'UID 0) peut, sur tous les hôtes, s'exécuter dans tout contexte utilisateur que on lui demandera son mot de passe (en supposant un comportement par défaut). Ajouter la balise NOPASSWD avant le dernier ALL permettrait également à root de faire la même chose sans qu'un mot de passe ne soit demandé (comme suit: root ALL=(ALL) NOPASSWD:ALL). ALL est un alias générique intrinsèque pour les différents types d'alias.

Mais revenons à Bob:

LIMITED_ADMINS ALL=(root) PRIV_ACTION

permettrait à bob et aux autres membres répertoriés de User_Alias LIMITED_ADMINS de s'exécuter (sur tous les hôtes, c'est ce à quoi sert la ALL) en tant qu'utilisateur root (groupe impliqué, mais qui pourrait être donné, voir man sudoers) les commandes données dans le Cmnd_Alias PRIV_ACTION. Ça s'ameliore. En supposant que vous écriviez ce script, vous pourriez autoriser différents paramètres, évitant ainsi d’écrire plusieurs scripts. /etc/sudoers prend volontiers des caractères génériques ressemblant à ceux du shell pour limiter les possibilités d'arguments pouvant être passés.

J'ai toujours constaté que les administrateurs n'utilisaient pas sudoers comme il se doit, c'est pourquoi j'ai apprécié le "Hack" respectif des deux livres "Linux Server Hacks" et "Linux Server Hacks Volume Two", ce qui m'a permis de commencer avec une utilisation plus sophistiquée de cette superbe installation.

Vous pouvez trouver toutes sortes de solutions compliquées - ce qui peut ne pas vraiment aider l'aspect sécurité - pour votre cas particulier, mais une fois que vous parlez le vocabulaire de base de /etc/sudoers, vous pouvez effectuer des exploits assez magiques :)

NB: gardez à l'esprit que vous pouvez également créer un nouveau fichier sous /etc/sudoers.d/ si vous vous en sentez enclin. Cela suppose que votre /etc/sudoers contient la ligne:

#includedir /etc/sudoers.d