Chapitre 4. Contrôle d’authentification et d’accès

Voici quelques fichiers de configuration importants auxquels PAM et NSS peuvent accéder :

Les limitations dans la sélection des mots de passe est implémentée par les modules PAM pam_unix(8) et pam_cracklib(8). Ils peuvent être configurés à l’aide de leurs paramètres.

	Astuce
	Les noms de fichiers des modules PAM ont le suffixe « .so ».

La gestion centralisée du système peut être mise en œuvre en utilisant le serveur centralisé LDAP Protocole léger d’accès aux répertoires (« Lightweight Directory Access Protocol ») pour administrer de nombreux systèmes semblables à UNIX ou autres sur le réseau. Le logiciel OpenLDAP est l’implémentation à sources ouvertes du protocole LDAP.

Sur un système Debian, le serveur LDAP fournit les informations de compte en utilisant PAM et de NSS avec les paquets libpam-ldap et libnss-ldap. Un certain nombre d’actions sont nécessaires pour l’activer (je n’ai pas utilisé cette configuration et ce qui suit est une information secondaire, veuillez la lire dans ce contexte) :

Consultez les documentations dans pam_ldap.conf(5) et « /usr/share/doc/libpam-doc/html/ » qui sont fournies par le paquet libpam-doc et « info libc 'Name Service Switch' fournie par le paquet glibc-doc.

De manière similaire, vous pouvez mettre en œuvre des systèmes centralisés de remplacement avec d’autres méthodes.

C’est la célèbre phrase de Richard M. Stallman en bas de l’ancienne page info su. Ne pas s’inquiéter : la commande su actuelle de https://iwawocd.cewmufwd.tk utilise PAM, on peut donc restreindre l’accès de su au groupe root en activant la ligne de « /etc/pam.d/su »comportant « pam_wheel.so ».

# here are the per-package modules (the "Primary" block)
password	requisite			pam_cracklib.so retry=3 minlen=8 difok=3
password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
password	optional	pam_gnome_keyring.so
# end of pam-auth-update config

La couche de transport de nombreux services populaires communique les messages, y compris les mots de passe d’authentification, en texte clair. C’est une très mauvaise idée de transmettre un mot de passe en texte clair dans la jungle d’Internet où il peut être intercepté. Vous pouvez faire tourner des services sur une couche de transport sécurisée « Sécurité de la couche de transport (« Transport Layer Security ») » (TLS) ou son prédécesseur « Secure Sockets Layer » (SSL) pour sécuriser par chiffrement la communication dans son ensemble, y compris le mot de passe.

Le chiffrement coûte du temps processeur. Comme solution de remplacement pour économiser du temps processeur, vous pouvez continuer à effectuer les communications en texte clair tout en ne sécurisant que le mot de passe avec un protocole d’authentification sécurisé comme « Authenticated Post Office Protocol » (APOP) pour POP et « Challenge-Response Authentication Mechanism MD5 » (CRAM-MD5) pour SMTP et IMAP. (Depuis peu, pour envoyer des messages de courrier électronique au travers d’internet à votre serveur de courrier depuis votre client de courrier, il est devenu habituel d’utiliser le port 587 en remplacement du port SMTP 25 habituel pour soumettre le courrier afin d’éviter le blocage du port 25 par le fournisseur d’accès au réseau tout en vous authentifiant avec CRAM-MD5.)

Le programme SSH, Shell sûr (« Secure Shell ») permet une communication chiffrée sûre entre deux machines qui ne sont pas « de confiance » au travers d’un réseau non sûr avec une authentification sûre. Il est constitué du client OpenSSH, de ssh(1), et du démon OpenSSH, sshd (8). SSH peut être utilisé pour « tunneler » de manière sécurisée un protocole de communications non sûr tel que POP et X au travers d’Internet à l’aide de la fonctionnalité de transfert de port.

Le client essaie de s’authentifier en utilisant l’authentification basée sur l’hôte, une clé publique d’authentification, une authentification par question-réponse ou une authentification par mot de passe. L’utilisation d’une authentification par clé publique permet la connexion à distance sans mot de passe. Consultez Section 6.3, « Le serveur et les utilitaires d’accès à distance (SSH) ».

Même lorsque vous exécutez des services sécurisés tels que des serveurs Secure Shell (SSH) ou PPTP (protocole de tunnel point-à-point), il existe toujours des risques d’intrusion à l’aide d’une attaque par force brute pour deviner le mot de passe, etc., à partir d’Internet. L’utilisation d’une politique de pare-feu (voir Section 5.7, « Infrastructure de netfilter ») avec les outils de sécurité suivants peut améliorer la situation en matière de sécurité.

Afin d’éviter que des personnes accèdent à votre machine avec les privilèges de l’administrateur, vous devez prendre les mesures suivantes :

• rendre impossible l’accès physique au disque dur ;

• verrouiller l’UEFI/BIOS et empêcher le démarrage à partir du support amovible

• définir un mot de passe pour la session interactive de GRUB ;

• verrouiller l’édition du menu de GRUB.

Avec un accès physique au disque, réinitialiser le mot de passe est relativement facile en suivant les étapes suivantes :

1. Monter le disque dur sur un PC ayant un UEFI/BIOS amorçable depuis un CD.

2. Démarrer le système avec un média de secours (disque d’amorçage de Debian, CD Knoppix, CD GRUB…).

3. Monter la partition racine avec les droits en lecture et écriture.

4. Éditer « /etc/passwd » de la partition racine et vider la seconde entrée du compte root.

Si vous avez l’accès en édition au menu GRUB (consultez Section 3.1.2, « Étage 2 : le chargeur initial »), avec grub-rescue-pc, il est encore plus simple d’effectuer les étapes suivantes au moment du démarrage :

L’interpréteur de commandes de l’administrateur est maintenant accessible sans mot de passe.

La seule solution logicielle raisonnable pour éviter tout ça est d’utiliser une partition racine (ou une partition « /etc ») chiffrée par logiciel en utilisant dm-crypt et initramfs (consultez Section 9.9, « Astuces de chiffrement des données »). Vous aurez alors toujours besoin d’un mot de passe pour vous connecter au système.

Les ACL sont un sur-ensemble des permissions normales comme expliqué dans la Section 1.2.3, « Permissions du système de fichiers ».

Les ACL sont utilisées dans les environnements de bureau modernes. Quand un périphérique USB formaté de stockage est auto-monté, comme par exemple « /media/penguin/SBSTICK », un utilisateur penguin normal peut exécuter :

 $ cd /media/penguin
 $ ls -la
total 16
drwxr-x---+ 1 root    root    16 Jan 17 22:55 .
drwxr-xr-x  1 root    root    28 Sep 17 19:03 ..
drwxr-xr-x  1 penguin penguin 18 Jan  6 07:05 USBSTICK

« + » dans la 11ème colonne indique que les ACL sont actives. Sans ACL, un utilisateur penguin normal ne pourrait réaliser une telle liste puisque penguin n’est pas dans le groupe root. Les ACL peuvent être vues comme :

 $ getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:penguin:r-x
group::---
mask::r-x
other::---

Ici :

Consultez « POSIX Access Control Lists on Linux », acl(5), getfacl(1) et setfacl(1) pour plus de renseignements.

sudo(8) est un programme conçu pour permettre à un administrateur système de donner des privilèges d’administration limités aux utilisateurs et d’enregistrer dans un journal les actions de l’administrateur (« root ». sudo ne demande que le mot de passe d’un utilisateur normal. Installez le paquet sudo et activez-le en définissant les options dans « /etc/sudoers ». Consultez l’exemple de configuration dans « /usr/share/doc/sudo/examples/sudoers » et Section 1.1.12, « Configuration de sudo ».

Mon utilisation de sudo sur un système avec un seul utilisateur (consultez Section 1.1.12, « Configuration de sudo ») est destinée à me protéger moi-même contre ma propre stupidité. Personnellement, je considère que l’utilisation de sudo est une meilleure alternative que l’utilisation permanente du système depuis le compte de l’administrateur. Par exemple, les modifications suivantes du propriétaire de « un_fichier » par « mon_nom » :

$ sudo chown my_name some_file

Bien sûr, si vous connaissez le mot de passe de root (comme beaucoup d’utilisateurs de Debian qui ont installé eux-mêmes leur système), n’importe quelle commande peut être lancée en tant qu’administrateur depuis un compte utilisateur par « su -c ».

PolicyKit est un composant du système d’exploitation permettant de contrôler les droits globaux sur les systèmes de type UNIX.

Les applications graphiques les plus récentes ne sont pas conçues pour fonctionner comme des processus privilégiés. Elles échangent avec les processus privilégiés par l’intermédiaire de PolicyKit pour réaliser les opérations d’administration.

PolicyKit limite de telles opérations aux comptes d’utilisateurs appartenant au groupe sudo sur le système Debian.

Consultez polkit(8).

Pour la sécurité du système, il est préférable de désactiver autant de programmes de serveurs que possible. Cela devient critique pour les services par l’intermédiaire du réseau. Avoir des services réseau inutilisés, qu’ils soient activés directement en tant que démon ou par l’intermédiaire du programme super-serveur, est considéré comme un risque de sécurité.

De nombreux programmes, tels que sshd(8), utilisent un contrôle d’accès basé sur PAM. Il y a de nombreuses manières de restreindre l’accès à certains serveurs de services :

Consulter Section 3.5, « Gestion du système », Section 4.5.1, « Fichiers de configuration auxquels accèdent PAM et NSS » et Section 5.7, « Infrastructure de netfilter ».

Le noyau Linux a évolué et prend en charge des fonctionnalités de sécurité introuvables dans les implémentations UNIX traditionnelles.

Linux prend en charge les attributs étendus qui accroissent les attributs UNIX traditionnels (Consulter xattr(7)).

Linux divise les privilèges traditionnellement associés au superutilisateur en unités distinctes, appelées capacités(7), qui peuvent être activées et désactivées indépendamment. Les capacités sont un attribut par fil d’exécution depuis la version 2.2 du noyau.

Le cadriciel Linux Security Module (LSM) fournit un mécanisme pour que divers contrôles de sécurité puissent être imbriquées dans de nouvelles extensions de noyau. Par exemple :

Étant donné que ces extensions peuvent restreindre davantage le modèle de privilège que les politiques ordinaires de modèle de sécurité de type Unix, même le pouvoir du superutilisateur peut être restreint. Il est conseillé de lire le document sur le cadriciel Linux Security Module (LSM) sur kernel.org.

Les espaces de noms de Linux enveloppent une ressource système globale dans une abstraction qui donne l’impression aux processus de l’espace de noms qu’ils ont leur propre instance isolée de la ressource globale. Les modifications apportées à la ressource globale sont visibles pour les autres processus membres de l’espace de noms, mais invisibles pour les autres processus. Depuis la version 5.6 du noyau, il existe 8 types d’espaces de noms (Consulter namespaces(7), unshare(1), nsenter(1)).

À partir de Debian 11 Bullseye (2021), Debian utilise une hiérarchie de cgroups unifiée (c’est-à-dire cgroups-v2).

Voici des exemples d’utilisation des espaces de noms avec cgroups pour isoler leurs processus et permettre le contrôle des ressources :

Ces fonctionnalités ne peuvent pas être réalisées par la Section 4.1, « Authentification normale d’UNIX ». Ces sujets avancés sont pour la plupart hors du périmètre de ce document d’introduction.