# 5. Sécurité et contrôle d'accès Cette section couvre les couches de contrôle d'accès qui se superposent sur un système Linux moderne, de la plus ancienne (permissions POSIX) à la plus fine (contrôle d'accès obligatoire). ## Permissions POSIX classiques Chaque fichier porte trois triplets de droits (lecture/écriture/exécution) pour le propriétaire, le groupe, et les autres — plus trois bits spéciaux : - **SUID** : un exécutable s'exécute avec les privilèges de son propriétaire plutôt que de l'utilisateur qui le lance (`passwd` en est l'exemple classique, pour permettre à un utilisateur de modifier son propre mot de passe stocké dans un fichier qu'il ne peut pas écrire directement). - **SGID** : sur un exécutable, hérite du groupe propriétaire ; sur un répertoire, tout fichier créé dedans hérite du groupe du répertoire. - **Sticky bit** : sur un répertoire partagé en écriture (ex. `/tmp`), seul le propriétaire d'un fichier peut le supprimer, même si d'autres ont un droit d'écriture sur le répertoire. ## ACL POSIX — au-delà des trois triplets Les **listes de contrôle d'accès** (`setfacl`/`getfacl`) permettent d'attribuer des permissions à des utilisateurs ou groupes additionnels au-delà du seul triplet propriétaire/groupe/autres — nécessaire dès qu'un partage de fichiers implique plus d'un groupe avec des besoins différents. ## Capabilities — découper les privilèges root Historiquement, un processus était soit root (tous les privilèges), soit non-root. Les **capabilities** (`man 7 capabilities`) découpent les pouvoirs de root en unités indépendantes accordables séparément : `CAP_NET_BIND_SERVICE` (lier un port < 1024 sans être root), `CAP_SYS_TIME` (modifier l'horloge système), `CAP_NET_ADMIN` (configuration réseau), etc. Un binaire peut recevoir une capability précise (`setcap`) sans jamais avoir besoin du SUID root complet — réduction directe de la surface d'attaque en cas de compromission de ce binaire. ## SELinux et AppArmor — contrôle d'accès obligatoire (MAC) Les permissions POSIX/ACL sont du contrôle d'accès **discrétionnaire** (DAC) : le propriétaire d'une ressource décide qui y accède. Le contrôle d'accès **obligatoire** (MAC) impose une politique système, indépendante de la volonté du propriétaire du fichier — même root peut être contraint. - **SELinux** : étiquette chaque objet (fichier, processus, port réseau...) d'un contexte de sécurité (`utilisateur:rôle:type:niveau`) et applique une politique déclarant quelles interactions entre types sont autorisées. Modèle très expressif mais réputé complexe à administrer. - **AppArmor** : approche basée sur des **chemins de fichiers** plutôt que des étiquettes abstraites — un profil par exécutable liste explicitement les chemins qu'il peut lire/écrire/exécuter. Plus simple à lire et à écrire qu'une politique SELinux, au prix d'une granularité un peu moins fine sur certains cas. Les deux mécanismes sont mutuellement exclusifs à l'exécution (un système utilise l'un ou l'autre, rarement les deux) et s'appuient sur le même point d'accroche noyau, **LSM** (*Linux Security Modules*). ## PAM et sudo **PAM** (*Pluggable Authentication Modules*) découple les programmes qui ont besoin d'authentifier un utilisateur (login, sudo, sshd...) du *comment* réellement authentifier (mot de passe local, empreinte biométrique, jeton matériel, annuaire distant) — chaque service référence une pile de modules dans `/etc/pam.d/`, échangeable sans modifier le programme lui-même. **sudo** s'appuie sur PAM pour l'authentification et sur `/etc/sudoers` (édité exclusivement via `visudo`, qui valide la syntaxe avant d'écrire, pour éviter de se retrouver avec un fichier corrompu et plus aucun accès root) pour la politique d'autorisation fine par utilisateur/groupe/commande. *(Schéma disponible : `schema.svg`, dans ce dossier.)*