sudo

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Sudo and the translation is 29% complete.

Outdated translations are marked like this.
Other languages:
English • ‎español • ‎français • ‎italiano • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

La commande sudo procure un moyen sûr et simple de configurer une escalade de privilèges, par exemple, permettre à des utilisateurs normaux d'exécuter certaines (ou toutes les) commandes en tant que root ou au nom d'un autre utilisateur, sans qu'ils aient à connaître le mot de passe de l'utilisateur auquel ils se substituent.

Lorsque vous voulez que certaines personnes accomplissent certaines tâches administratives sans leur donner un accès total en tant que root, utiliser sudo est la meilleure option. En effet, sudo permet de contrôler qui peut faire quoi. Ce guide est une petite introduction à ce puissant outil.

Cet article est une rapide introduction. Le paquet app-admin/sudo est bien plus puissant que ce qui est décrit ici. Il a des options supplémentaires permettant l'édition de fichier en tant qu'autre utilisateur (sudoedit), s'exécuter depuis un script (donc reste en arrière-plan, lit le mot de passe depuis l'entrée standard et non depuis le clavier,…), etc.

Merci de lire les pages de manuel de sudo et de sudoers pour plus d'informations.

Installation

Options de la variable USE

USE flags for app-admin/sudo Allows users or groups to run commands as other users

gcrypt Use message digest functions from dev-libs/libgcrypt instead of sudo's
ldap Add LDAP support (Lightweight Directory Access Protocol)
libressl Use message digest functions from dev-libs/libressl instead of sudo's
nls Add Native Language Support (using gettext - GNU locale utilities)
offensive Let sudo print insults when the user types the wrong password
pam Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
sasl Add support for the Simple Authentication and Security Layer
secure-path Replace PATH variable with compile time secure paths
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
sendmail Allow sudo to send emails with sendmail
skey Enable S/Key (Single use password) authentication support
sssd Add System Security Services Daemon support
system-digest Use message digest functions from dev-libs/libgcrypt, dev-libs/libressl or dev-libs/openssl instead of sudo's internal SHA2 implementation

Emerge

root #emerge --ask app-admin/sudo

Configuration

Journalisation

Un autre avantage de sudo est qu'il peut enregistrer tous les essais (réussis ou non) de lancement d'applications. C'est très utile pour retrouver la personne qui a fait l'erreur que l'on a mis 10 heures à corriger :)

Accorder des autorisations

Le paquet app-admin/sudo permet à l'administrateur système d'autoriser certains utilisateurs à exécuter des applications auxquelles ils n'ont normalement pas accès. À la différence de setuid, sudo permet un contrôle plus fin de qui peut exécuter une certaine commande, et quand.

Avec sudo vous pouvez établir une liste claire de qui peut exécuter une application donnée. Si vous utilisiez le bit setuid, n'importe quel utilisateur ( ou n'importe quel utilisateur d'un groupe donné, selon l'autorisation accordée) serait capable d'exécuter cette application. Vous pouvez (et devriez probablement) demander à l'utilisateur de fournir un mot de passe lorsqu'il désire exécuter l'application concernée.

La configuration de sudo est gérée par le fichier /etc/sudoers. Ce fichier ne devrait jamais être édité via nano /etc/sudoers ou vim /etc/sudoers ou n'importe quel autre éditeur. Lorsque vous désirez changer ce fichier, vous devriez utiliser visudo .

Syntaxe de base

La partie la plus difficile de sudo, c'est la syntaxe du fichier /etc/sudoers. La syntaxe de base ressemble à ceci :

CODE Syntaxe de base de /etc/sudoers
user  host = commands

Cette syntaxe indique à sudo que l'utilisateur, identifié par user et connecté au système host peut exécuter n'importe quelle commande listée dans commands en tant qu'utilisateur root. Un exemple plus réel pourrait rendre cela plus clair : autoriser l'utilisateur swift à exécuter emerge s'il est connecté à l'hôte local :

A more real-life example might make this more clear: To allow the user larry to execute emerge when he is logged in on localhost:

CODE Exemple réaliste de /etc/sudoers
swift  localhost = /usr/bin/emerge
Note
Le nom d'hôte doit corresponde à ce que retourne la commande hostname.
Note
In the simplest case, commands must be fully qualified paths to executables: hence /usr/bin/emerge not just emerge. Paths can also contain wildcards and may refer to entire directories. See the manpage for details.
Attention !
N'autorisez pas un utilisateur à exécuter une application qui lui permette d'élever ses autorisations. Par exemple, autoriser des utilisateurs à exécuter emerge en tant que root peut en effet leur donner un accès complet au système en tant que root parce qu'emerge peut être manipulé pour changer le système de fichier actif à l'avantage de l'utilisateur. Si vous ne faites pas confiance à vos utilisateurs de sudo, ne leur donnez aucune autorisation.

Le nom d'utilisateur peut aussi être remplacé par un nom de groupe. Dans ce cas, vous devriez commencer le nom du groupe avec un signe %. Par exemple, pour autoriser n'importe quel utilisateur du groupe wheel à exécuter emerge :

CODE Autoriser les membres du groupe wheel à éxecuter emerge
%wheel  localhost = /usr/bin/emerge

Vous pouvez étendre la ligne pour autoriser plusieurs commandes (au lieu de faire une entrée simple pour chacune des commandes). Par exemple, pour autoriser le même utilisateur à exécuter, pas seulement emerge ,mais aussi ebuild et emerge-webrsync en tant que root :

CODE Commandes multiples
swift  localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync

Vous pouvez aussi spécifier une commande précise et pas seulement un outil. Ceci est utile pour restreindre l'utilisation d'un outil donné à un certain jeu d'options de commande. L'outil sudo autorise les passe-partout du style shell (aussi connu sous le nom de meta caractères ou de caractères glob) à être utilisés dans les noms de fichiers ou dans les arguments de la ligne de commande dans le fichier sudoers. Notez qu'il ne s'agit pas d'expressions régulières.

Testons cela :

user $sudo emerge -uDN world
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
  
    #1- Respect the privacy of others.
    #2- Think before you type.
    #3- With great power comes great responsibility.
  
Password: ## (Enter the user password, not root!)

Le mot de passe requis par sudo est le propre mot de passe de l'utilisateur, pas celui de root. Ceci garantit qu'aucun terminal que vous avez laissé accidentellement ouvert aux autres ne pourra être utilisé par des gens mal intentionnés.

Vous devriez savoir que sudo ne modifie pas la variable ${PATH} : toute commande placée après sudo est traitée dans votre environnement. Si vous voulez que l'utilisateur exécute un outil dans /sbin par exemple, il devrait fournir le chemin complet à sudo de cette manière :

Syntaxe de base avec LDAP

Les options suivantes de la variable USE sont nécessaire pour la prise en charge de LDAP.

USE flags for app-admin/sudo Allows users or groups to run commands as other users

gcrypt Use message digest functions from dev-libs/libgcrypt instead of sudo's
ldap Add LDAP support (Lightweight Directory Access Protocol)
libressl Use message digest functions from dev-libs/libressl instead of sudo's
nls Add Native Language Support (using gettext - GNU locale utilities)
offensive Let sudo print insults when the user types the wrong password
pam Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
sasl Add support for the Simple Authentication and Security Layer
secure-path Replace PATH variable with compile time secure paths
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
sendmail Allow sudo to send emails with sendmail
skey Enable S/Key (Single use password) authentication support
sssd Add System Security Services Daemon support
system-digest Use message digest functions from dev-libs/libgcrypt, dev-libs/libressl or dev-libs/openssl instead of sudo's internal SHA2 implementation
The above template uses deprecated functionality. Help us update this template!

Lorsque vous utilisez sudo avec LDAP, sudo lira la configuration depuis le serveur LDAP Server également. C'est pourquoi vous devez éditer deux fichiers.

FILE /etc/ldap.conf.sudoUtilisez chmod 400 après avoir terminé
# Voir ldap.conf(5) et  README.LDAP pour les détails
# Ce fichier ne devrait être lisible que par root
  
# directives prises en charge: host, port, ssl, ldap_version
# uri, binddn, bindpw, sudoers_base, sudoers_debug
# tls_{checkpeer,cacertfile,cacertdir,randfile,ciphers,cert,key}
  
host ldap.example.com
port 389
  
base dc=example,dc=com
  
uri ldap://ldap.example.com/
#uri ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock
  
ldap_version 3
#ssl start_tls
  
sudoers_base ou=SUDOers,dc=example,dc=com
#sudoers_debug 2
  
bind_policy soft
FILE /etc/nsswitch.confAjoutez la ligne des sudoers
sudoers:     ldap files

Vous devez aussi ajouter l'entrée LDAP suivante pour sudo.

Note
Il a été conçu pour que la branche des sudoers soit au sommet de l'arbre pour des raisons de sécurité. Vous pouvez donc avoir des droits d'accès différents de ldap pour lire/écrire dans cette branche
CODE Ldap Entry for Sudo
version: 1
DN: ou=SUDOers,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
objectClass: domainRelatedObject
associatedDomain: example.com
ou: SUDOers
  
DN: cn=defaults,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOption: env_reset
  
DN: cn=root,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: root
sudoCommand: ALL
sudoHost: ALL
sudoUser: root
  
DN: cn=%wheel,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoCommand: ALL
sudoHost: ALL
sudoOption: !authenticate
sudoUser: %wheel
CODE Entrée Ldap Entry pour le groupe wheel
version: 1
DN: cn=wheel,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: wheel
description: Wheel Group
gidNumber: 10
memberUid: useradmin1
memberUid: root

La configuration des sudoer sur LDAP est similaire à celles des fichiers avec quelques différences. Lisez à propos de sudo avec LDAP à partir du lien ci-dessous .[1]

Utiliser des alias

Dans des environnements plus étendus, avoir à entrer tous les utilisateurs encore et encore (ou des hôtes, ou des commandes) peut sembler très rébarbatif. Pour faciliter l'administration de /etc/sudoers, vous pouvez définir des alias. Le format pour déclarer un alias est très simple :

CODE Déclarer des alias dans /etc/sudoers
Host_Alias hostalias = hostname1, hostname2, ...
User_Alias useralias = user1, user2, ...
Cmnd_Alias cmndalias = command1, command2, ...

Un alias qui marche toujours, pour toute position, est l'alias ALL (pour faire une distinction claire entre ce qui est un alias et ce qui ne l'est pas, il est recommandé d'utiliser des lettres capitales dans les alias). Comme vous l'avez sans doute déduit, l'alias ALL est un alias représentant tout ce qui est possible en matière de réglage.

Un exemple d'utilisation de l'alias ALL pour autoriser n'importe quel utilisateur à exécuter la commande shutdown lorsqu'il est connecté localement est :

CODE Autoriser n'importe quel utilisateur à éxecuter shutdown
ALL  localhost = /sbin/shutdown

Un autre exemple consiste à autoriser l'utilisateur swift à exécuter la commande emerge en tant que root sans tenir compte de l'hôte auquel il est connecté :

CODE Autoriser un utilisateur à exécuter une application sans tenir compte de l'hôte auquel il est connecté
larry   ALL = /usr/bin/emerge

Plus intéressant encore, consiste à définir un jeu d'utilisateurs qui peuvent exécuter des programmes d'administration (tels que emerge et ebuild ) sur le système et un groupe d'administrateurs qui peuvent changer le mot de passe de n'importe quel utilisateur, exception faite de root !

CODE Utiliser des alias pour des utilisateurs et des commandes
User_Alias  SOFTWAREMAINTAINERS = swift, john, danny
User_Alias  PASSWORDMAINTAINERS = swift, sysop
Cmnd_Alias  SOFTWARECOMMANDS    = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias  PASSWORDCOMMANDS    = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root
  
SOFTWAREMAINTAINERS  localhost = SOFTWARECOMMANDS
PASSWORDMAINTAINERS  localhost = PASSWORDCOMMANDS

Non-root execution

It is also possible to have a user run an application as a different, non-root user. This can be very interesting when running applications as a different user (for instance apache for the web server) and want to allow certain users to perform administrative steps as that user (like killing zombie processes).

Inside /etc/sudoers list the user(s) in between ( and ) before the command listing:

CODE Non-root execution syntax
users  hosts = (run-as) commands

For instance, to allow larry to run the kill tool as the apache or gorg user:

CODE Non-root execution example
Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill
 
larry   ALL = (apache, gorg) KILL

With this set, the user can run sudo -u to select the user he wants to run the application as:

user $sudo -u apache pkill apache

An alias can set for the user to run an application as using the Runas_Alias directive. Its use is identical to the other _Alias directives we have seen before.

Passwords and default settings

By default, sudo asks the user to identify himself using his own password. Once a password is entered, sudo remembers it for 5 minutes, allowing the user to focus on his tasks and not repeatedly re-entering his password.

Of course, this behavior can be changed: set the Defaults: directive in /etc/sudoers to change the default behavior for a user.

For instance, to change the default 5 minutes to 0 (never remember):

CODE Changing the timeout value
Defaults:larry  timestamp_timeout=0

A setting of -1 would remember the password indefinitely (until the system reboots).

A different setting would be to require the password of the user that the command should be run as and not the users' personal password. This is accomplished using runaspw. In the following example we also set the number of retries (how many times the user can re-enter a password before sudo fails) to 2 instead of the default 3:

CODE Requiring the root password instead of the user's password
Defaults:john   runaspw, passwd_tries=2

Another interesting feature is to keep the DISPLAY variable set so that graphical tools can be executed:

CODE Keeping the DISPLAY variable alive
Defaults:john env_keep=DISPLAY

Dozens of default settings can changed using the Defaults: directive. Fire up the sudoers manual page and search for Defaults.

To allow a user to run a certain set of commands without providing any password whatsoever, start the commands with NOPASSWD:, like so:

CODE Allowing emerge to be ran as root without asking for a password
larry     localhost = NOPASSWD: /usr/bin/emerge

Bash completion

Users that want bash completion with sudo need to run this once.

user $sudo echo "complete -cf sudo" >> $HOME/.bashrc

Zshell completion

Users that want zsh completion for sudo can set the following in .zprofile and .zshrc respectively

FILE .zprofileAdding zshell completion
if [[ $EUID != 0 ]]; then
    typeset -xT SUDO_PATH sudo_path
    typeset -U sudo_path
    sudo_path=({,/usr/local,/usr}/sbin(N-/))
    alias sudo="sudo env PATH=\"SUDO_PATH:$PATH\""
fi
FILE .zshrcAdding zshell completion
zstyle ':completion:*:sudo:*' environ PATH="$SUDO_PATH:$PATH"

With the above change, all commands in the /sbin, /usr/sbin and /usr/local/sbin locations will be available to the shell for completion when the command is prefaced with 'sudo'.

Utiliser sudo

Lister les privilèges

Pour connaître vos propres autorisations, exécutez la commande sudo -l :

user $sudo -l
User swift may run the following commands on this host:
    (root)   /usr/libexec/xfsm-shutdown-helper
    (root)   /usr/bin/emerge
    (root)   /usr/bin/passwd [a-zA-Z0-9_-]*
    (root)   !/usr/bin/passwd root
    (apache) /usr/bin/pkill
    (apache) /bin/kill

Si des commandes se trouvent dans /etc/sudoers qui ne requièrent pas que vous saisissiez un mot de passe, il ne sera pas non plus nécessaire de saisir un mot de passe pour lister les entrées. Autrement, on pourrait vous demander votre mot de passe s'il n'est pas mémorisé.

Prolonger le temps de mémorisation du mot de passe

Par défaut, si un utilisateur a saisi son mot de passe pour s'identifier auprès de sudo, ce mot de passe est mémorisé 5 minutes. Si l'utilisateurs désire prolonger ce bail, il peut exécuter sudo -v pour remettre à zéro le compteur de temps de manière telle qu'il dispose d'encore 5 minutes avant que sudo ne lui réclame à nouveau son mot de passe

user $sudo -v

L'inverse consiste à tuer le compteur avec sudo -k.

References

  1. [1]Sudoers LDAP man Page