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

J'installe 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 consistent à héberger des machines virtuelles avec VirtualBox et à servir des fichiers avec Samba.

Pour Samba, plusieurs comptes d'utilisateurs doivent être configurés afin 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, les gens essaient de faire des choses avec ce compte qui nécessitent des privilèges élevés - cela fait apparaître 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 mien a été le premier compte créé, il semble donc supposer que je suis le seul utilisateur à disposer des pouvoirs sudo.

Je veux désigner un autre utilisateur comme "administrateur de premier recours", pour ainsi dire, et ce ne peut pas être l'utilisateur de compte partagé, car tout le monde doit connaître le mot de passe de ce compte, donc je veux que ses privilèges soient strictement limités. Il ne peut pas s'agir de mon compte, car je ne communique aucun mot de passe à d'autres personnes 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 faire en personne, alors je les ai ajoutés /etc/sudoers. Comment puis-je dire à Ubuntu que lorsqu'il doit élever des privilèges pour quelque chose, il doit d'abord demander son compte?

Résumer:

• Comptes sur la machine: Alice, Bob, Carol, Dave, Eliza.
• Lors de l'installation d'Ubuntu, Alice était le premier utilisateur, ajouté lors du processus d'installation.
• "Dave" est en fait un compte utilisé par de nombreuses personnes, qui ne peut pas y accéder /etc/sudoerscar son mot de passe est de notoriété publique.
• Bob a été configuré pour être un compte «administratif» dans Gnome et est correctement saisi /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 en étant 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 buckaroo et ait l'habitude de l'utiliser su -pour effectuer des tâches d'administration étendues).

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

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

1. sudo

2. PolicyKit

Le premier est utilisé lorsque vous exécutez explicitement une commande avec sudoou un élément de menu dont la commande est encapsulée gksu(comme Synaptic Package Manager ).
Dans ce cas, le mot de passe requis est celui de l'utilisateur appelant, généralement l'utilisateur connecté.

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

Vous pouvez identifier PolicyKit à partir du petit triangle noir et de l'étiquette Détails . Comme vous pouvez le voir, si plusieurs utilisateurs sont dans le admingroupe, vous pouvez choisir dans la liste quel utilisateur utiliser pour l'authentification.

Compte tenu de tout cela, les deux sudoet PolicyKit sont beaucoup plus compliqués, en ce qui concerne les configurations qui peuvent être réalisées: vous pouvez configurer une action qui peut être exécutée sans mot de passe, exécutée uniquement par un utilisateur ou un groupe particulier, etc.

En ce qui concerne 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 administrateurs, si je comprends bien), et vous pouvez changer dans la liste, quel utilisateur vous souhaitez utiliser pour l'authentification.

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

De toute évidence, ce sudoserait le premier choix pour moi dans un tel cas. Le point apparaît majeur à la plupart que les administrateurs (réels) n'utilisent pas vraiment /etc/sudoersau maximum la mesure du possible ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

La plupart des administrateurs finissent par utiliser uniquement certaines des règles existantes et ajoutent des utilisateurs, ou pire, ajoutent simplement des utilisateurs au sudogroupe pour lequel une règle existe généralement sur les configurations Ubuntu ( %sudo...). Bien sûr, cela donne aux utilisateurs respectifs le règne gratuit et la pleine puissance du compte superutilisateur.

Compte tenu de votre commentaire:

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

Je pense que vous ne l'utilisez pas autant que possible.

Dans un scénario comme le vôtre, je rédigerais littéralement les quelques actions auxquelles Bob doit se limiter. 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/dashau lieu de #!/usr/bin/env bash) et s'exécuteraient probablement avec un shell qui est utilisé ailleurs pour des tâches privilégiées ( /bin/dashou /bin/sh). Ce ne sont que des précautions. En dehors de cela, je veillerais à coder en dur tous les chemins absolus vers les binaires et à en utiliser le moins possible. Par exemple, lorsque j'utilise bash/ dashje préfère builtins à commands (voir man bash). Vous pouvez rendre cela maintenable en affectant à une variable le chemin absolu et en vous référant au programme basé sur cette variable ($VIRSHau lieu de /usr/bin/virsh). Si vous le pouvez, examinez 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 sshdl'authentification par clé publique. De toute évidence, vous n'en avez pas besoin.

Assurez-vous d' chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>empêcher quiconque, mais rootbon, de le bricoler. Soyez également prudent avec setuidet les setgidbits activés sur les binaires cibles ( findpeuvent être utilisés pour les repérer). Supposons pour le moment que votre script réside /usr/sbin/priv-action.

Modifiez maintenant votre /etc/sudoers. noexecpeut également être utilisé pour empêcher d'autres binaires que ceux explicitement autorisés. Il y a en fait beaucoup de 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 sudoersfichier, mais vous pouvez tout aussi bien utiliser un Group_Alias( man sudoers) ou un groupe système 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, la ligne magique permet bob(ou plutôt aux utilisateurs répertoriés ci-dessous 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. Examinons donc d'abord les pièces sur une ligne "Spécifications utilisateur". Voici man sudoersaide:

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

Exemple de ligne (présente sur la plupart des configurations Ubuntu):

root    ALL=(ALL) ALL

Cela signifie qu'un utilisateur nommé root (à utiliser #0pour le lier à l'UID 0) peut, sur tous les hôtes, s'exécuter dans n'importe quel contexte utilisateur, mais que son mot de passe lui sera demandé (en supposant un comportement par défaut). L'ajout de la NOPASSWDbalise avant la dernière ALLpermettrait alors rootde faire de même sans qu'on lui demande un mot de passe (comme ça:) root ALL=(ALL) NOPASSWD:ALL. ALLest un alias générique intrinsèque pour les différents types d'alias.

Mais revenons à Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

permettrait à d' bobautres membres de la liste User_Alias LIMITED_ADMINSde s'exécuter (sur tous les hôtes, c'est à cela que ALLsert) en tant qu'utilisateur root(groupe implicite, mais pourrait être donné, voir man sudoers) les commandes données dans le Cmnd_Alias PRIV_ACTION. Ça s'ameliore. En supposant toujours que vous écrivez ce script, vous pouvez autoriser divers paramètres, évitant ainsi d'écrire plusieurs scripts. /etc/sudoersprend volontiers des caractères génériques de type shell pour limiter les possibilités d'arguments autorisés à passer.

J'ai toujours constaté que les administrateurs n'utilisent pas sudoersla façon dont il devrait être utilisé, 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 une utilisation plus sophistiquée de cette grande installation.

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

NB: gardez à l'esprit que vous pouvez également créer un nouveau fichier en dessous /etc/sudoers.d/si vous le souhaitez. Cela suppose que votre /etc/sudoerscontient la ligne:

#includedir /etc/sudoers.d

Il n'y a qu'un seul super utilisateur sous Unix / Linux, son nom est root, mais les sudoers sont des utilisateurs qui peuvent devenir root. Vous devez utiliser des groupes:

newgrp admins

puis affectez les utilisateurs à ce groupe:

chgrp alice admins

puis ajoutez le groupe admins au fichier de configuration sudoers comme si le groupe était un utilisateur.

Mise à jour

Ou vous pouvez ajouter n'importe quel utilisateur au groupe d'administration:

chgrp alice admin