Dans mon article précédent, "Les vrais administrateurs système ne font pas sudo", j'ai discuté de l'utilisation abusive vraiment horrible de sudo par certaines distributions. Dans cet article, qui est partiellement extrait du chapitre 11 de mon livre, "Utiliser et administrer Linux, de zéro à SysAdmin, Volume 1 :Premiers pas", j'explore quelques cas d'utilisation valides pour sudo .
Cas d'utilisation 1 :copie de fichiers à distance
J'ai récemment écrit un court programme Bash pour copier certains fichiers MP3 d'une clé USB sur un hôte réseau vers un autre hôte réseau. Les fichiers sont copiés dans un répertoire spécifique sur le serveur que j'exécute pour une organisation à laquelle j'appartiens, d'où ils peuvent être téléchargés et lus.
Mon programme fait quelques autres choses, comme changer le nom des fichiers avant qu'ils ne soient copiés afin qu'ils soient automatiquement triés par date sur la page Web. Il supprime également tous les fichiers de la clé USB après avoir vérifié que le transfert s'est correctement déroulé. Ce joli petit programme a quelques options telles que -h pour afficher l'aide, -t pour le mode test et quelques autres.
Mon programme, aussi merveilleux soit-il, doit s'exécuter en tant que root afin d'exécuter ses fonctions principales. Malheureusement, cette organisation ne compte que quelques personnes à part moi qui s'intéressent à l'administration de nos systèmes audio et informatiques, ce qui me met dans la position de trouver des personnes semi-techniques à former pour se connecter à l'ordinateur que nous utilisons pour effectuer le transfert et exécutez ce petit programme.
Ce n'est pas que je ne peux pas gérer le programme moi-même, mais je ne suis pas toujours là pour diverses raisons telles que les voyages et la maladie. Même lorsque je suis présent, en tant que "Lazy SysAdmin", j'aime que d'autres fassent mon travail pour moi. J'écris donc des scripts pour automatiser ces tâches et j'utilise sudo pour oindre quelques utilisateurs pour exécuter les scripts. De nombreuses commandes Linux nécessitent que l'utilisateur soit root pour s'exécuter. Cela protège le système contre les dommages accidentels tels que ceux causés par ma propre stupidité et les dommages intentionnels d'un utilisateur aux intentions malveillantes.
Fais ce sudo que tu fais si bien
Le sudo est un outil pratique qui me permet, en tant qu'administrateur système avec un accès root, de déléguer la responsabilité de toutes ou de quelques tâches administratives à d'autres utilisateurs de l'ordinateur comme je l'entends. Cela me permet d'effectuer cette délégation sans compromettre le mot de passe root et ainsi maintenir un haut niveau de sécurité sur l'hôte.
Supposons, par exemple, que j'ai donné à l'utilisateur normal, "ruser", l'accès à mon programme Bash, myprog , qui doit être exécuté en tant que root afin d'exécuter une partie de ses fonctions. Tout d'abord, l'utilisateur se connecte en tant que ruser avec son propre mot de passe. L'utilisateur utilise ensuite la commande suivante pour exécuter myprog .
sudo myprog
Le sudo programme vérifie le /etc/sudoers fichier et vérifie que ruser est autorisé à exécuter myprog . Si oui, sudo demande à l'utilisateur d'entrer son propre mot de passe, et non le mot de passe root. Une fois que l'utilisateur a saisi son propre mot de passe, le programme est exécuté. sudo enregistre également les faits de l'accès à myprog avec la date et l'heure d'exécution du programme, la commande complète et l'utilisateur qui l'a exécuté. Ces données sont enregistrées dans /var/log/security .
Je trouve qu'avoir le journal de chaque commande exécutée par sudo être utile à la formation. Je peux voir qui a fait quoi et s'il a effectivement entré la commande correctement.
J'ai fait cela pour déléguer l'autorité d'exécuter un seul programme à moi-même et à un autre utilisateur. Cependant, sudo peut être utilisé pour faire beaucoup plus. Il peut permettre à l'administrateur système de déléguer l'autorité de gestion des fonctions réseau ou des services spécifiques à une seule personne ou à un groupe d'utilisateurs de confiance. Il permet de déléguer ces fonctions tout en protégeant la sécurité du mot de passe root.
Configuration du fichier sudoers
En tant qu'administrateur système, je peux utiliser le /etc/sudoers fichier pour permettre aux utilisateurs ou aux groupes d'utilisateurs d'accéder à une seule commande, à des groupes de commandes définis ou à toutes les commandes. Cette flexibilité est la clé de la puissance et de la simplicité d'utilisation de sudo pour la délégation.
J'ai copié l'intégralité de sudoers fichier dans Figure 1 de l'hébergeur sur lequel je l'utilise afin de le déconstruire pour vous. Je l'ai trouvé très déroutant la première fois que je l'ai rencontré. J'espère que ce ne sera pas si obscur pour vous au moment où nous aurons terminé. J'aime le fait que les distributions basées sur Red Hat ont tendance à avoir des fichiers de configuration par défaut avec de nombreux commentaires et exemples pour fournir des conseils. Cela rend les choses plus faciles car il est beaucoup moins nécessaire de googler.
N'utilisez pas votre éditeur standard pour modifier les sudoers dossier. Utiliser le visudo car elle est conçue pour permettre toute modification dès que le fichier est enregistré et que vous quittez l'éditeur. Il est possible d'utiliser des éditeurs en plus de vi de la même manière que visudo .
Commençons par analyser ce fichier au début avec quelques types d'alias.
Alias d'hôte
La section Host Aliases est utilisée pour créer des groupes d'hôtes sur lesquels des commandes ou des alias de commande peuvent être utilisés pour fournir un accès. L'idée de base est que ce fichier unique sera maintenu pour tous les hôtes d'une organisation et copié dans /etc sur chaque hôte. Certains hôtes, tels que les serveurs, peuvent ainsi être configurés en groupe pour permettre à certains utilisateurs d'accéder à des commandes spécifiques telles que la possibilité de démarrer et d'arrêter des services tels que HTTPD, DNS, la mise en réseau, la possibilité de monter des systèmes de fichiers, etc.
Les adresses IP peuvent être utilisées à la place des noms d'hôte dans les alias d'hôte.
## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
##
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
##
## This file must be edited with the 'visudo' command.
## Host Aliases
## Groups of machines. You may prefer to use hostnames (perhaps using
## wildcards for entire domains) or IP addresses instead.
# Host_Alias FILESERVERS = fs1, fs2
# Host_Alias MAILSERVERS = smtp, smtp2
## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem
User_Alias AUDIO = dboth, user
## Command Aliases
## These are groups of related commands...
## Networking
# Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool
## Installation and management of software
# Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum
## Services
# Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig
## Updating the locate database
# Cmnd_Alias LOCATE = /usr/bin/updatedb
## Storage
# Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount
## Delegating permissions
# Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp
## Processes
# Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall
## Drivers
# Cmnd_Alias DRIVERS = /sbin/modprobe
# Defaults specification
#
# Refuse to run if unable to disable echo on the tty.
#
Defaults !visiblepw
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
## user MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS
## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
## Allows members of the users group to mount and unmount the
## cdrom as root
# %users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom
## Allows members of the users group to shutdown this system
# %users localhost=/sbin/shutdown -h now
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d
################################################################################
# Added by David Both, 11/04/2017 to provide limited access to myprog #
################################################################################
#
AUDIO guest1=/usr/local/bin/myprog Illustration 1 :Un fichier sudoers par défaut avec mes modifications en gras.
Alias d'utilisateur
Le groupe suivant d'exemples de configuration est celui des alias d'utilisateur. Cela permet à root de trier les utilisateurs dans des groupes alias afin qu'un groupe entier puisse avoir accès à certaines fonctionnalités root. Pour le petit programme que j'ai écrit, j'ai ajouté l'alias suivant à cette section qui définit l'alias AUDIO et attribue deux utilisateurs à cet alias.
User_Alias AUDIO = dboth, ruser
C'est possible, comme indiqué dans les sudoers fichier lui-même, pour utiliser simplement les groupes Linux définis dans le /etc/groups fichier au lieu d'alias. Si vous avez déjà défini un groupe qui répond à vos besoins, tel que "audio", utilisez ce nom de groupe précédé d'un % signe comme ceci :%audio lors de l'attribution de commandes disponibles aux groupes ultérieurement dans les sudoers fichier.
Alias de commande
Plus bas les sudoers file est une section avec des alias de commande. Ces alias sont des listes de commandes associées, telles que des commandes réseau ou des commandes requises pour installer des mises à jour ou de nouveaux packages RPM. Ces alias permettent à l'administrateur système d'autoriser facilement l'accès à des groupes de commandes.
Il existe un certain nombre d'alias déjà configurés dans cette section qui facilitent la délégation de l'accès à des types de commandes spécifiques. Nous n'avons besoin d'aucun d'entre eux pour notre cas d'utilisation.
Paramètres par défaut de l'environnement
La section suivante définit certaines variables d'environnement par défaut. L'élément le plus intéressant dans cette section est le !visiblepw ligne qui empêche sudo de s'exécuter si l'environnement utilisateur est configuré pour afficher le mot de passe. Il s'agit d'une précaution de sécurité qui ne doit pas être outrepassée.
Section de commande
Cette section est la partie principale des sudoers dossier. Tout ce qui est nécessaire peut être fait sans tous les alias en ajoutant suffisamment d'entrées ici. Les alias facilitent grandement les choses en utilisant les alias déjà définis pour indiquer sudo qui peut faire quoi sur quels hôtes. Les exemples sont explicites une fois que vous avez compris la syntaxe de cette section. Examinons donc la syntaxe que nous trouvons dans la section de commande. Dans la Figure 2 nous avons une entrée générique pour notre utilisateur, ruser.
ruser ALL=(ALL) ALL Illustration 2 :Une entrée générique indiquant que l'utilisateur peut exécuter n'importe quel programme sur n'importe quel hôte en tant qu'utilisateur.
Le premier ALL de la ligne indique que cette règle s'applique à tous les hôtes. Le second ALL permet à l'utilisateur d'exécuter des commandes comme n'importe quel autre utilisateur. Par défaut, les commandes sont exécutées en tant qu'utilisateur root mais ruser peut spécifier sur le sudo ligne de commande qu'un programme est exécuté comme n'importe quel autre utilisateur. Le dernier ALL signifie que ruser peut exécuter toutes les commandes sans restriction. Cette entrée rendrait effectivement ruser root. Nous n'utiliserons pas cette entrée car nous ne voulons pas que cet utilisateur dispose de toutes ces fonctionnalités.
Notez qu'il existe une entrée pour root, comme illustré dans la Figure 3 . Cette entrée permet à root d'avoir un accès complet à toutes les commandes sur tous les hôtes.
root ALL=(ALL) ALL
Illustration 3 :Une entrée qui indique que toot peut exécuter n'importe quel programme sur n'importe quel hôte en tant qu'utilisateur.
Mais, bien sûr, je devais essayer ceci, alors j'ai commenté la ligne dans Figure 3 et, en tant que root, a essayé d'exécuter chown sans sudo . Cela a fonctionné – à ma grande surprise. Ensuite, j'ai utilisé sudo chown et cela a échoué avec le message "root is not in the sudoers file. Cet incident sera signalé. Cela signifie que root peut tout exécuter en tant que root, mais rien lors de l'utilisation de sudo commande. Cela empêcherait root d'exécuter des commandes comme d'autres utilisateurs via le sudo commande, mais root a de nombreuses façons de contourner cette restriction.
L'entrée dans Figure 4 est celui que j'ai ajouté pour contrôler l'accès à myprog . Il spécifie que les utilisateurs répertoriés dans le groupe AUDIO, tel que défini près du haut des sudoers fichier, n'ont accès qu'à un seul programme, myprog , sur un hôte, guest1.
AUDIO guest1=/usr/local/bin/myprog
Illustration 4 :C'est l'entrée que j'ai ajoutée pour permettre aux utilisateurs qui font partie du groupe AUDIO d'accéder à myprog sur l'hôte, guest1.
Notez que la syntaxe de la ligne dans la Figure 4 spécifie uniquement l'hôte sur lequel cet accès doit être autorisé et le programme. Il ne précise pas que l'utilisateur peut exécuter le programme comme n'importe quel autre utilisateur.
Contourner les mots de passe
Illustration 5 illustre l'utilisation de NOPASSWORD pour autoriser les utilisateurs spécifiés dans le groupe AUDIO à exécuter myprog sans avoir besoin de saisir leurs mots de passe.
AUDIO guest1=NOPASSWORD : /usr/local/bin/myprog
Illustration 5 :Cette entrée hypothétique permettrait aux utilisateurs faisant partie du groupe AUDIO d'accéder à myprog sans avoir besoin de saisir leurs mots de passe.
Je ne l'ai pas fait pour mon programme car je pense que les utilisateurs avec sudo l'accès doit s'arrêter et réfléchir à ce qu'ils font et cela peut aider un peu à cela. J'ai juste utilisé l'entrée de mon petit programme comme exemple.
Roue
La spécification de la roue dans la section de commande des sudoers fichier comme illustré à la Figure 6 permet à tous les utilisateurs du groupe wheel d'exécuter toutes les commandes sur n'importe quel hôte. Le groupe de roues est défini dans le /etc/group fichier et les utilisateurs doivent y être ajoutés au groupe pour que cela fonctionne. Le % signe précédant le nom du groupe signifie que sudo devrait rechercher ce groupe dans le /etc/group fichier.
%wheel ALL = (ALL) ALL
Illustration 6 :Cette entrée indique que tous les utilisateurs qui sont membres du groupe wheel tel que défini dans le /etc/group peut exécuter toutes les commandes sur n'importe quel hôte.
C'est un bon moyen de déléguer l'accès root complet à plusieurs utilisateurs sans fournir le mot de passe root. Le simple fait d'ajouter un utilisateur au groupe de roues lui donne accès à tous les pouvoirs root. Il fournit également un moyen de surveiller leurs activités via les entrées de journal créées par sudo . Certaines distributions telles qu'Ubuntu ajoutent les identifiants des utilisateurs au groupe de roues dans /etc/group qui leur permet d'utiliser le sudo commande pour utiliser toutes les commandes privilégiées.
Cas d'utilisation 2 :la présentation
Nous pensons généralement aux présentations en termes de diapositives lisses créées par LibreOffice Impress ou PowerPoint, de transitions animées et de graphiques, mais ce n'est pas nécessairement le cas. Le 3 mars de cette année, j'ai présenté une session prolongée à Open Source 101 à Columbia en Caroline du Sud, intitulée "Utilisation et configuration de Bash".
Maintenant, si vous assistez à une longue session sur l'utilisation de Bash, pourquoi voudriez-vous voir beaucoup de diapositives fantaisistes ? Personnellement, je veux voir Bash en cours d'utilisation. J'ai donc créé un script Bash qui est devenu ma présentation. Je ne suis pas une dactylographe rapide ou précise, cela m'a également permis de préprogrammer toutes les commandes que je voulais démontrer dans le script Bash, donc je n'aurais qu'à appuyer sur Enter touche pour passer à la diapositive suivante contenant du texte ou pour émettre une commande. Cela a très bien fonctionné pour moi et les participants semblaient également l'apprécier car c'était un très bon cas d'utilisation pour les scripts Bash.
Ceci est pertinent car une et une seule des commandes de ce script shell Bash de 1500 lignes nécessitait le privilège root. Il serait incroyablement dangereux de se connecter en tant que root et d'exécuter l'intégralité du programme. Et s'il devait y avoir une erreur qui supprimait ou déformait certains fichiers importants au niveau du système ? En tant qu'administrateur système et programmeur Bash, je ne suis pas parfait et des erreurs se produisent.
La réponse était donc d'exécuter le programme en tant qu'utilisateur "étudiant" et d'utiliser le sudo commande comme préfixe de la seule commande nécessitant un accès privilégié. Même au milieu de ma présentation, taper le mot de passe de l'utilisateur étudiant était facile. J'ai également utilisé ceci dans ma présentation comme exemple d'une utilisation appropriée de sudo .
La configuration pour ce cas d'utilisation est la même que pour le cas précédent, juste avec des noms d'utilisateur et des noms de commande différents.
Réflexions finales
J'ai utilisé sudo dans ces cas pour un objectif très limité - fournir à un ou deux utilisateurs l'accès à une seule commande. J'ai accompli cela avec deux lignes si vous ignorez mes propres commentaires. Déléguer l'autorité d'effectuer des tâches spécifiques à des utilisateurs qui n'ont pas d'accès root est simple et peut vous faire gagner beaucoup de temps en tant qu'administrateur système. Il peut également améliorer considérablement la sécurité en fournissant un accès à des commandes spécifiques uniquement lorsque cela est nécessaire.
Le sudo La commande génère également des entrées de journal qui peuvent aider à détecter les problèmes. Les sudoers file offre une pléthore de fonctionnalités et d'options de configuration. Vérifiez le man fichiers pour sudo et sudoers pour les détails sales et sales.
[ Télécharger maintenant :Un guide de l'administrateur système sur les scripts Bash. ]