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


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 principaux rôles consistent à héberger des machines virtuelles avec VirtualBox et à servir des fichiers avec Samba.

Pour Samba, plusieurs comptes utilisateurs doivent être configurés pour que différentes personnes puissent se connecter aux partages Samba depuis 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 requièrent des privilèges élevés - cela provoque l'affichage de la boîte de dialogue "Veuillez entrer un mot de passe administrateur". Cependant, cette boîte de dialogue demande mon mot de passe - quand j'ai configuré la machine, la première était le mien, donc il semble que je sois le seul utilisateur à avoir les pouvoirs sudo.

Je veux désigner un autre utilisateur comme "administrateur de premier recours", et il ne peut pas 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. Cela ne peut pas être mon compte, car je ne dis pas aux autres personnes mon mot de passe, et je ne serai pas sur le site assez souvent pour le saisir moi-même. Il y a cependant quelqu'un qui pouvez faites-le 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 demander leur compte d'abord?

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 que beaucoup de gens utilisent, qui ne peuvent pas être dans /etc/sudoers parce que son mot de passe est la connaissance du public.
  • 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 lors de la connexion 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 qu’elles sont connectées en tant qu’Alice, le système doit demander les informations d’identification d’Alice (bien qu’Alice soit en quelque sorte un sysadmin Buckaroo et a l’habitude d’utiliser su - effectuer des tâches d'administration étendues).

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


11
2017-12-13 19:16


origine


Une alternative serait d'autoriser les commandes liées à la virtualisation à utiliser automatiquement les privilèges d'administrateur. Je suis sûr que j'ai lu une question à ce sujet, mais j'ai oublié. - Oxwivi
Un rapide googling me dit que vous le faites du même sudoers fichier, vous pouvez vérifier c'est page de manuel pour plus d'informations. - Oxwivi
Je considérais cela quand j'étais en train d'éditer sudoers: ce n'est pas un premier recours en raison de problèmes de sécurité. Voir aussi la réponse de enzotib - une partie du problème était la confusion entre sudo et PolicyKit. - Brighid McDonnell


Réponses:


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

  1. sudo

  2. PolicyKit

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

Le second est utilisé lorsqu'une application compatible PolicyKit tente d'effectuer une action privilégiée. Dans ce cas, l'application demande à l'autorité locale de PolicyKit (via D-Bus) si l'action peut être exécutée. L'autorité locale, par l'intermédiaire d'un agent d'authentification, demande à l'utilisateur actif de prouver son identité. Les fenêtres de dialogue sont les suivantes (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 voir, si plus d'un utilisateur est dans le admin groupe, vous pouvez choisir dans la liste quel utilisateur utiliser pour l’authentification.

Compte tenu de tout cela, les deux sudo et PolicyKit sont beaucoup plus compliqués, en ce qui concerne les configurations possibles: 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.

Pour en venir à 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 (le seul utilisateur admin, si je comprends bien), et vous pouvez changer à partir de 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 effectuées via l'interface graphique, cela devient moins fréquent), vous n'avez aucun moyen immédiat et simple de choisir l'utilisateur pour l'authentification.


9
2017-12-13 21:33



J'ai l'impression de mieux comprendre la situation maintenant. Je vous remercie. - Brighid McDonnell


Clairement, sudo serait le premier choix pour moi dans un tel cas. Le point majeur semble être que la plupart des administrateurs (réels) 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 utiliser seulement une partie des existant règles et l'ajout d'utilisateurs, ou pire, simplement en ajoutant des utilisateurs au sudo groupe pour lequel une règle existe généralement sur les configurations Ubuntu (%sudo ...). Ceci, bien sûr, donne aux utilisateurs respectifs la liberté 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 autant que possible.

Dans un scénario comme le vôtre, j'écrirais littéralement les quelques actions auxquelles Bob doit être limité. En fait, c'est ce que j'ai fait sur un serveur que je gère pour permettre à deux utilisateurs particuliers de redémarrer un invité KVM particulier sur un hôte. Les scripts contiennent un hashbang avec un chemin absolu vers l'interpréteur (par ex. #!/bin/dash au lieu de #!/usr/bin/env bash) et probablement exécuté 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 binaires et d’en utiliser le moins possible. Par exemple. en utilisant bash/dash je préférerais builtins over commands (voir man bash). Vous pouvez rendre cela maintenable en assignant une variable au chemin absolu et en vous référant au programme basé sur cette variable ($VIRSH au lieu de /usr/bin/virsh). Si vous le pouvez, examinez le code de tous les 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 authentification par clé publique. De toute évidence, vous n'avez pas besoin de ça.

Assurez-vous de chown root: <the-script>; chmod u=rw,a=,a+rx <the-script> pour empêcher quiconque mais root propre de bricoler avec elle. Soyez également prudent avec setuid et setgid bits activés sur les binaires cibles (findpeut être utilisé 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 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. Alors assurez-vous de consulter man sudoers.

Maintenant, je préfère nommer les utilisateurs (User_Alias) dans mon sudoers fichier, mais vous pourriez tout aussi bien utiliser un Group_Alias (man sudoers) ou un groupe de systèmes réel (par ex. %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

Last but not least vient la ligne magique pour permettre bob (ou plutôt les utilisateurs listés sous LIMITED_ADMINS) pour 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. Donc, commençons par creuser les parties sur une ligne "User Specification". Ici man sudoers aide:

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

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

root    ALL=(ALL) ALL

Cela dit qu'un utilisateur nommé  root (utilisation #0 pour l'attacher à l'UID 0) peut, sur tous les hôtes, s'exécuter dans n'importe quel contexte utilisateur, mais on lui demandera son mot de passe (en supposant un comportement par défaut). Ajouter le NOPASSWD tag avant le dernier ALL serait alors également permettre root faire de même sans qu'on vous demande un mot de passe (comme ça: root ALL=(ALL) NOPASSWD:ALL). ALL est un alias intrinsèque de type joker pour les différents types d'alias.

Mais revenons à Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

permettrait bob et d'autres membres de la liste User_Alias LIMITED_ADMINS pour courir (sur tous les hôtes, c'est ce que le ALL est pour) en tant qu'utilisateur root (groupe impliqué, mais 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 pouvez autoriser divers paramètres, évitant ainsi d'écrire plusieurs scripts. /etc/sudoers prend volontiers des caractères génériques de type shell pour limiter les possibilités d'arguments pouvant être transmis.

J'ai toujours constaté que les administrateurs n'utilisent pas sudoers la 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 avec une utilisation plus sophistiquée de cette grande facilité.

Vous pouvez trouver toutes sortes de solutions compliquées - ce qui peut ne pas être très utile pour la 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 sentez si enclin. Cela suppose votre /etc/sudoers contient la ligne:

#includedir /etc/sudoers.d

6
2018-02-01 01:59





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

newgrp admins

puis attribuez les utilisateurs à ce groupe:

chgrp alice admins

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

Mettre à jour

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

chgrp alice admin

-1
2017-12-13 19:48



Désolé j'ai frappé la touche de tabulation et l'envoyer sans le terminer. - Francisco Valdez
Commentaire zorched basé sur une réponse incomplète. Essayer la réponse actuelle. En supposant que l'exposition supplémentaire est pour les futurs lecteurs peut-être moins familiarisés avec les tâches de l'administrateur système. - Brighid McDonnell
Bien sûr, je ne voulais pas être arrogant, il y a un site d'échange de piles à propos de administrateur système - Francisco Valdez
Je sais que ServerFault existe. Je demande ici parce que c'est un comportement spécifique à Ubuntu. - Brighid McDonnell
AUTANT QUE JE SACHE: adduser <user>, addgroup <group> et adduser <user> <group> sont la voie préférée sur Debian / Ubuntu. - 0xC0000022L