web-dev-qa-db-fra.com

Pourquoi le système a-t-il /etc/sudoers.d? Comment devrais-je le modificateur?

La dernière fois, j'ai posé une question sur le risque de ceux-ci (dans/etc/sudoers):

    user_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
    %group_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Pendant que je réfléchissais à ce problème, j'ai trouvé le répertoire /etc/sudoers.d . Les fichiers du répertoire devraient avoir des fonctions similaires à celles de/etc/sudoers (ce qui signifie que les scripts ci-dessus sont toujours problématiques, même dans /etc/sudoers.d). Cependant, un article disait que nous ne devrions pas utiliser le répertoire car nous ne pouvons pas utiliser visudo pour éditer des fichiers. en elle. En d’autres termes, nous perdons le droit d’utiliser Sudo si nous commettons une erreur dans le répertoire.

Si cela est vrai, pourquoi avons-nous /etc/sudoers.d ? Ou avons-nous un bon moyen d’éditer des fichiers dans /etc/sudoers.d ?

ubuntusudosudoershttpd
44
aob

Les modifications apportées aux fichiers dans /etc/sudoers.d restent en place si vous mettez à niveau le système. Cela peut empêcher les verrouillages d’utilisateur lors de la mise à niveau du système. Ubuntu a tendance à aimer ce comportement. D'autres distributions utilisent également cette disposition.

D'après mon expérience, les règles sur les fichiers de ce répertoire sont plus souples que pour /etc/sudoers. Cela a inclus:

  • Les erreurs dans le fichier n'ont pas causé l'échec de Sudo. Cependant, le fichier a été ignoré.
  • Les règles de permission semblent moins strictes. Cela permet au groupe concerné ou autre de lire le fichier. Je ne crois pas que c'était possible avec /etc/sudoers. Les autorisations d'écriture doivent être limitées à root pour maintenir la sécurité. La version actuelle de Sudo pour Ubuntu autorise les autorisations de lecture pour les groupes ou autres. (Cette fonctionnalité permet d’auditer l’accès à Sudo sans recourir à un accès root.)

La commande visudo ne fait par défaut que /etc/sudoers. Il éditera et vérifiera n'importe quel fichier que vous spécifiez avec l'option -f. J'utilise cette fonctionnalité pour éditer des fichiers qui seront automatiquement installés en tant que /etc/sudoers ou dans /etc/sudoders.d. Cependant, les définitions d'autres fichiers peuvent ne pas être trouvées. Il est préférable de rendre le fichier indépendant.

La possibilité de disposer de fichiers autonomes permet à une application d'activer la fonctionnalité Sudo lors de l'installation et de les supprimer une fois qu'elle est désinstallée. Les outils de configuration automatisés peuvent également utiliser cette fonctionnalité.

J'ai utilisé cette fonctionnalité pour isoler les modifications requises pour accorder l'accès à des groupes d'utilisateurs spécifiques sur des systèmes spécifiques.

38
BillThor

Oui, vous pouvez utiliser visudo pour éditer ces fichiers. Tout ce que vous avez à faire est de spécifier le nom du fichier que vous souhaitez modifier avec l'option -f. Par exemple:

visudo -f /etc/sudoers.d/somefilename

Ou, si nécessaire:

Sudo visudo -f /etc/sudoers.d/somefilename

Documentation

De man visudo:

-f sudoers
Spécifiez et remplacez l’emplacement du fichier sudoers. Avec cette option, visudo éditera (ou vérifiera) le fichier sudoers de votre choix, au lieu du fichier par défaut,/etc/sudoers. Le fichier de verrouillage utilisé est le fichier sudoers spécifié auquel est ajouté ".tmp". En mode check-only uniquement, l'argument de -f peut être "-", indiquant que les utilisateurs sudoers seront lus à partir de l'entrée standard.

En résumé:

  1. Syntaxe: visudo et visudo -feffectuer la même vérification de la syntaxe} _.

  2. Autorisations/Propriété: En tant que fonctionnalité ajoutée pour aider à l'administration de grands systèmes , les fichiers édités sous visudo -f ne sont pas contrôlés en termes de propriété ou d'autorisations: cela permet de vérifier la syntaxe d'un fichier hors ligne ou dans le cadre de un système de contrôle de révision.

Pourquoi utiliser /etc/sudoers.d/

Généralement, /etc/sudoers est sous le contrôle du gestionnaire de paquets de votre distribution. Si vous avez apporté des modifications à ce fichier et que le gestionnaire de packages souhaite le mettre à niveau, vous devrez examiner manuellement les modifications et approuver leur fusion dans la nouvelle version. En plaçant vos modifications locales dans un fichier du répertoire /etc/sudoers.d/, vous évitez cette étape manuelle et les mises à niveau peuvent être effectuées automatiquement.

Quand Sudo ignore-t-il un fichier dans /etc/sudoers?

Si votre fichier /etc/sudoers contient la ligne:

#includedir /etc/sudoers.d

alors Sudo lira les fichiers du répertoire /etc/sudoers.d.

Les exceptions sont:

  1. Fichiers dont le nom se termine par ~
  2. Fichiers dont les noms contiennent un caractère .

Ceci est fait (a) pour la commodité des gestionnaires de paquets et (b) pour que les fichiers de sauvegarde des éditeurs soient ignorés.

58
John1024

pourquoi avons-nous /etc/sudoers.d?

Parce qu'il est plus facile pour des outils automatisés (tels que Chef ou Puppet) de déposer des fichiers individuels dans ce répertoire, plutôt que d'apporter des modifications à /etc/sudoers, qui pourrait être fragile.

Les fichiers dans /etc/sudoers.d sont (en fait) concaténés. Vous verrez plusieurs autres instances de ce modèle dans /etc, telles que /etc/cron.d et /etc/logrotate.d.

18
Roger Lipscombe

L'utilisation de visudo -f, comme indiqué dans certaines réponses, présente un autre avantage: il existe une option correspondante, -c ou --check, qui vérifie que vous ne disposez pas d'informations non valides dans un fichier sudoers.d ou dans tout autre fichier que vous souhaitez placer dans sudoers.d. C’est VRAIMENT très pratique dans les cas mentionnés avec des outils automatisés, comme vous pouvez le faire par exemple.

Sudo visudo -c -q -f /home/myuser/mysudoers && \
Sudo chmod 600 /home/myuser/mysudoers && \
Sudo cp /home/myuser/mysudoers /etc/sudoers.d/mysudoers

Ceci vérifie le fichier en silence (pas de sortie à cause de -q) et seulement si cela ne renvoie PAS une erreur (exit 1 signifie un fichier sudoers invalide), il copiera le fichier dans sudoers.d, de cette façon vous pourrez le créer et travaillez dessus sans avoir à le corriger du premier coup (utiliser Sudo visudo -f /etc/sudoers.d/myfile doit réussir ou le contenu sera ignoré si vous ne le corrigez pas).

En outre, un Mot d'avertissement concernant ces déclarations des autres réponses.

D'après mon expérience, les règles concernant les fichiers de ce répertoire sont plus souples que pour/etc/sudoers. Cela a inclus:

Les erreurs dans le fichier n'ont pas causé l'échec de Sudo. Cependant, le fichier a été ignoré. Les règles de permission semblent moins strictes. J'autorise le groupe concerné à lire le fichier. Je ne crois pas que ce soit possible avec/etc/Sudo.

Les fichiers de /etc/sudoers.d doivent respecter la même syntaxe que/etc/sudoers car, sous le capot, le système concatène simplement tous les fichiers dont le dernier est "gagnant" s'il existe plusieurs entrées pour le même fichier. cadre singulier.

Si les autorisations sont horriblement incorrectes (écriture sur le monde) sur les fichiers de /etc/sudoers.d/, ils sont alors ignorés. Cela peut être la cause de l'ignorance des fichiers non valides, sinon vous pouvez sérieusement briser la commande Sudo en ayant un sudoers invalide. Fichier .d avec les autorisations appropriées.

Vous pouvez autoriser les fichiers sudoers à être lisibles par tout le monde. Si vous autorisez accidentellement l'autorisation d'accès en écriture "autre" dont vous avez besoin, un autre utilisateur ou un terminal root exécutera cette commande. Cela peut également échouer si le fichier appartient à quelqu'un d'autre que root: root.

Sudo chmod 644 /etc/sudoers.d/mysudoers
Sudo chown root:root /etc/sudoers.d/mysudoers

Je viens de confirmer que si j'exécute chmod o+w /etc/sudoers.d/vagrant, je ne peux plus utiliser Sudo en tant qu'utilisateur errant, il me demande mon mot de passe, puis échoue.

Lorsque j'ai exécuté Sudo -l pour afficher les autorisations de commande appliquées en tant qu'un autre utilisateur Sudo valide, j'ai également reçu un avertissement concernant les autorisations de fichier. C'est la même commande que j'ai utilisée pour confirmer que l'utilisateur 'vagabond' a perdu Sudo lorsque j'ai appliqué les autorisations o+w au fichier lui donnant les autorisations Sudo.

11
dragon788

Juste un petit ajout à une réponse générale ... aucune des autres réponses n'a résolu mon problème, à savoir que l'ordre est important.

Si vos lignes fonctionnent avec sudoers mais pas avec sudoers.d, essayez de déplacer le #include ou de changer l'ordre des fichiers sudoers.d (en ajoutant un nombre avec préfixe). Il semble que l'élément le plus spécifique devrait figurer en premier dans le fichier.

J'ai eu quelque chose comme:

somebody ALL=(ALL): somecommand
somebody ALL=(someoneelse) NOPASSWD: somecommand

Et le second n'a aucun effet car le premier correspond déjà. NOPASSWD n'est pas une condition, mais un moyen de modifier l'action.

Et ce n'était pas évident car ce n'était pas dans un seul fichier, à cause du répertoire sudoers.d.

1
Peter