4.4. Contrôles administratifs
Lors de l'administration d'un ordinateur privé, l'utilisateur doit effectuer certaines tâches en tant que super-utilisateur ou en s'appropriant les privilèges du super-utilisateur au moyen d'un programme setuid tel que sudo ou su. Un programme setuid utilise l'ID utilisateur (UID) du propriétaire du programme plutôt que l'utilisateur se servant du programme. Ces programmes sont reconnaissables par la lettre minuscule s apparaissant dans la section propriétaire d'un listage au format détaillé (long listing), comme dans l'exemple suivant :
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su |
Toutefois, les administrateurs système d'une société doivent faire des choix quant au niveau d'accès administratif dont les utilisateurs de la société devraient disposer sur leur ordinateur. Grâce à un module PAM nommé pam_console.so, certaines activités normalement réservées exclusivement au super-utilisateur, telles que le redémarrage ou le montage de médias amovibles, sont permises au premier utilisateur établissant une connexion à la console physique (consultez le chapitre intitulé Modules d'authentification enfichables (PAM) du Guide de référence de Red Hat Enterprise Linux pour obtenir de plus amples informations sur le module pam_console.so). Cependant, d'autres tâches d'administration système importantes telles que la modification de paramètres réseau, la configuration d'une nouvelle souris ou le montage de périphériques réseau ne sont pas possibles sans privilèges administratifs. Dans de telles circonstances, les administrateurs système doivent déterminer le degré d'accès dont les utilisateurs de leur réseau devraient disposer.
4.4.1. Autorisation de l'accès super-utilisateur (ou root)
Si les utilisateurs au sein d'une société font partie d'un groupe de personnes dignes de confiance et douées en informatique, alors l'autorisation de disposer de l'accès super-utilisateur n'est pas forcément une mauvaise idée. La possibilité d'obtenir l'accès super-utilisateur permet aux utilisateurs individuels de résoudre des petits problèmes comme l'ajout de périphériques ou la configuration d'interfaces réseau, donnant ainsi aux administrateurs système plus de temps pour se concentrer sur la sécurité réseau et autres problèmes d'importance.
D'autre part, l'attribution de l'accès super-utilisateur à des utilisateurs individuels peut engendrer les problèmes suivants :
Mauvaise configuration de l'ordinateur — Les utilisateurs disposant de l'accès super-utilisateur peuvent mal configurer leur ordinateur et nécessiter d'assistance ou pire encore, peuvent ouvrir des brèches de sécurité sans même s'en rendre compte.
Exécution de services non-sécurisés — Il se peut que des utilisateurs disposant de l'accès super-utilisateur exécutent des serveurs non-sécurisés sur leur ordinateur, comme par exemple FTP ou Telnet, et mettent par là-même potentiellement en danger des noms d'utilisateur et mots de passe dans la mesure où ces derniers sont transmis en clair sur le réseau.
Exécution de pièces jointes de courrier électronique en tant que super-utilisateur — Bien que les virus transmis par courrier électronique affectant Linux soient rares, ils existent tout de même. Toutefois, les seuls cas dans lesquels ils représentent une menace sont lorsqu'ils sont exécutés en tant que super-utilisateur.
4.4.2. Refus de l'accès super-utilisateur
Si, pour les raisons mentionnées ou pour toute autre raison, un administrateur s'inquiète de la possibilité offerte aux utilisateurs de se connecter en tant que super-utilisateur, le mot de passe root ne devrait pas être divulgué et l'accès au niveau d'exécution un ou au mode mono-utilisateur devrait être refusé en protégeant le chargeur de démarrage à l'aide d'un mot de passe (consultez la Section 4.2.2 pour obtenir de plus amples informations sur le sujet).
Le Tableau 4-1 illustre certaines manières auxquelles un administrateur peut recourir pour s'assurer fermement que toute connexion en tant que super-utilisateur est bien refusée :
| Méthode | Description | Conséquences | Sans conséquences | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Changement du shell super-utilisateur | Modifiez le fichier /etc/passwd et changez le shell de /bin/bash à /sbin/nologin. |
|
| |||||||||||||||
| Désactivation de l'accès super-utilisateur au moyen de tout terminal de contrôle (tty). | Un fichier /etc/securetty vide empêche la connexion en tant que super-utilisateur sur tout périphérique relié à l'ordinateur. |
|
| |||||||||||||||
| Désactivation des connexions SSH du super-utilisateur | Modifiez le fichier /etc/ssh/sshd_config et donnez au paramètre PermitRootLogin la valeur no. |
|
| |||||||||||||||
| Utilisation de PAM pour limiter l'accès super-utilisateur aux services | Modifiez le fichier relatif au service cible dans le répertoire /etc/pam.d/. Assurez-vous que pam_listfile.so est bien nécessaire pour l'authentification.[a] |
|
| |||||||||||||||
| Remarques : a. Consultez la Section 4.4.2.4 pour obtenir de plus amples informations. | ||||||||||||||||||
Tableau 4-1. Méthodes pour désactiver le compte super-utilisateur
4.4.2.1. Désactivation du shell super-utilisateur (root)
Afin d'empêcher les utilisateurs de se connecter directement en tant que super-utilisateur, l'administrateur système peut définir le shell du compte super-utilisateur comme /sbin/nologin dans le fichier /etc/passwd. Ce faisant, tout accès au compte super-utilisateur au moyen de commandes nécessitant un shell, comme par exemple les commandes su et ssh, sera bloqué.
 | Important |
|---|---|
Les programmes ne nécessitant pas un accès au shell, tels que les clients de messagerie ou la commande sudo, ont toujours accès au compte super-utilisateur. |
4.4.2.2. Désactivation des connexions super-utilisateur
Afin de restreindre davantage l'accès au compte super-utilisateur, les administrateurs peuvent désactiver les connexions root à la console en éditant le fichier /etc/securetty. Ce dernier énumère tous les périphériques sur lesquels le super-utilisateur peut se connecter. Si le fichier n'existe pas du tout, le super-utilisateur peut se connecter en utilisant tout périphérique de communication présent sur le système, que ce soit par le biais de la console ou d'une interface réseau brute. Cette situation est dangereuse car un utilisateur peut se connecter à sa machine en tant que super-utilisateur via Telnet, en transmettant son mot de passe en clair sur le réseau. Par défaut, le fichier /etc/securetty de Red Hat Enterprise Linux permet seulement au super-utilisateur de se connecter à la console reliée physiquement à l'ordinateur. Pour empêcher le super-utilisateur de se connecter, supprimez le contenu de ce fichier en saisissant la commande suivante :
echo > /etc/securetty |
 | Avertissement |
|---|---|
Un fichier /etc/securetty vierge n'empêche pas le super-utilisateur de se connecter à distance à l'aide de la suite d'outils OpenSSH, car la console n'est ouverte qu'une fois l'authentification effectuée. |
4.4.2.3. Désactivation des connexions SSH super-utilisateur
Afin d'empêcher les connexions super-utilisateur par le biais du protocole SSH, éditez le fichier de configuration du démon SSH (/etc/ssh/sshd_config). Modifiez la ligne stipulant :
# PermitRootLogin yes |
en :
PermitRootLogin no |
4.4.2.4. Désactivation du super-utilisateur à l'aide de PAM
PAM, au moyen du module /lib/security/pam_listfile.so, offre une grande flexibilité pour ce qui est du refus de l'accès de certains comptes. Grâce à PAM, l'administrateur peut indiquer au module une liste d'utilisateurs auxquels refuser la connexion. Ci-dessous figure un exemple de la manière dont le module est utilisé pour vsftpd du serveur FTP dans le fichier de configuration de PAM /etc/pam.d/vsftpd (le signe \ placé à la fin de la première ligne dans l'exemple suivant n'est pas nécessaire si la directive est sur une seule ligne) :
auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed |
Cette directive indique à PAM de consulter le fichier /etc/vsftpd.ftpusers et de refuser l'accès au service à tout utilisateur mentionné dans la liste. L'administrateur peut changer le nom de ce fichier s'il le souhaite et peut garder des listes séparées pour chaque service ou il peut utiliser une liste principale pour refuser l'accès à de multiples services.
Si l'administrateur souhaite refuser l'accès à de multiples services, il peut ajouter une ligne similaire aux services de configuration PAM, tels que /etc/pam.d/pop et /etc/pam.d/imap pour des clients de messagerie ou /etc/pam.d/ssh pour des clients SSH.
Pour obtenir de plus amples informations sur PAM, consultez le chapitre intitulé Modules d'authentification enfichables (PAM) du Guide de référence de Red Hat Enterprise Linux.
4.4.3. Restriction de l'accès super-utilisateur
Plutôt que de refuser complètement l'accès au super-utilisateur, l'administrateur peut décider d'autoriser l'accès uniquement via des programmes setuid tels que su ou sudo.
4.4.3.1. La commande su
Lorsque l'utilisateur saisit la commande su, le système demande le mot de passe root et, après authentification, donne une invite du shell root.
Une fois connecté par le biais de la commande su, l'utilisateur devient le super-utilisateur et détient alors l'accès administratif absolu au système. De plus, une fois que l'utilisateur s'est octroyé les privilèges du super-utilisateur, il peut, dans certains cas, utiliser la commande su pour se changer en tout autre utilisateur sur le système et ce, sans devoir saisir de mot de passe.
En raison de la puissance de ce programme, les administrateurs au sein d'une société souhaiteront peut-être restreindre le nombre de personnes ayant accès à cette commande.
Une des façons les plus simples de procéder consiste à ajouter des utilisateurs au groupe administratif spécial appelé wheel. Pour ce faire, saisissez la commande suivante en étant connecté en tant que super-utilisateur :
usermod -G wheel <username> |
Dans la commande précédente, remplacez <username> par le nom d'utilisateur à ajouter au groupe wheel.
Afin d'utiliser le Gestionnaire d'utilisateurs à ces fins, cliquez sur Menu principal (sur le panneau) => Paramètres de système => Utilisateurs et groupes ou saisissez la commande system-config-users à une invite du shell. Sélectionnez l'onglet Utilisateurs, choisissez l'utilisateur parmi la liste d'utilisateurs et cliquez sur Propriétés dans le menu de boutons (ou choisissez Fichier => Propriétés dans le menu déroulant).
Sélectionnez ensuite l'onglet Groupes et cliquez sur le groupe nommé wheel, comme le montre la Figure 4-2.
Dans un éditeur de texte, ouvrez ensuite le fichier de configuration PAM pour su, /etc/pam.d/su et supprimez le commentaire
auth required /lib/security/$ISA/pam_wheel.so use_uid |
Ce faisant, seuls les membres du groupe administratif wheel pourront utiliser le programme.
 | Remarque |
|---|---|
Par défaut, le super-utilisateur fait partie du groupe wheel. |
4.4.3.2. La commande sudo
La commande sudo fournit une autre approche lors de l'attribution de l'accès administratif aux utilisateurs. Lorsqu'un utilisateur de confiance fait précéder une commande administrative par sudo, le système lui demande de saisir son propre mot de passe. Ensuite, une fois authentifié et en supposant que la commande est permise, la commande administrative est exécutée comme si l'opération était effectuée par le super-utilisateur.
Le format de base de la commande sudo est le suivant :
sudo <command> |
Dans l'exemple précédent, <command> serait remplacé par une commande normalement réservée au super-utilisateur, comme par exemple mount.
| Important |
|---|---|
Il est recommandé aux utilisateurs de la commande sudo de s'assurer de bien se déconnecter avant de quitter leur ordinateur car toute personne utilisant la commande sudo peut réutiliser la dite commande sans devoir saisir à nouveau un mot de passe et ce, pendant une durée de cinq minutes. Ce paramètre peut être modifié au moyen du fichier de configuration /etc/sudoers. |
La commande sudo offre une grande flexibilité. Par exemple, seuls les utilisateurs mentionnés dans le fichier de configuration /etc/sudoers sont autorisés à utiliser la commande sudo et cette dernière est exécutée dans le shell de l'utilisateur, et non pas dans un shell root. Dans de telles circonstances, le shell root peut être complètement désactivé, comme l'explique la Section 4.4.2.1.
La commande sudo fournit également un certain nombre de traces permettant toute vérification. Toute authentification réussie est journalisée dans le fichier /var/log/messages et la commande exécutée est elle enregistrée dans le fichier /var/log/secure, accompagnée par le nom de l'utilisateur l'ayant engendrée.
Un autre avantage de la commande sudo réside dans la possibilité pour l'administrateur, d'autoriser l'accès de différents utilisateurs à des commandes spécifiques en fonction de leurs besoins.
Les administrateurs souhaitant changer le fichier de configuration de sudo, /etc/sudoers, devraient utiliser la commande visudo.
Afin d'octroyer à une personne la totalité des privilèges administratifs, saisissez la commande visudo et ajoutez dans la partie relative à la spécification des privilèges de l'utilisateur, une ligne semblable à celle qui suit :
juan ALL=(ALL) ALL |
Cet exemple stipule que l'utilisateur, juan, est autorisé à utiliser la commande sudo à partir d'un hôte quelconque et peut exécuter toute commande.
L'exemple ci-dessous illustre le niveau de granularité possible lors de la configuration de sudo :
%users localhost=/sbin/shutdown -h now |
Cet exemple stipule que tout utilisateur peut exécuter la commande /sbin/shutdown -h now tant qu'elle est exécutée à partir de la console.
La page de manuel relative à sudoers contient un inventaire détaillé des options utilisables pour ce fichier.