Permissions Linux avancées : ACL, capabilities et SELinux basics

Avec chmod et chown, vous gérez les permissions de base en Linux. Mais dès que vous avez besoin de donner accès à plusieurs utilisateurs avec des niveaux différents, d'accorder des privilèges root sans accorder root complet, ou de sécuriser un serveur de production, le système classique rwxrwxrwx ne suffit plus.

Cet article couvre les permissions avancées : ACL pour la granularité multi-utilisateurs, sticky bit/SUID/SGID pour les exécutables, capabilities pour les privilèges limités, attributs étendus pour l'immuabilité, et umask pour la configuration par défaut. C'est le fondement d'une sécurité robuste.

Juste pour fixer les idées : chmod 755 file = rwxr-xr-x (propriétaire lecture/écriture/exécution, autres lecture/exécution). chown user:group file change le propriétaire. chgrp group file change le groupe. Pour la plupart des usages, ces trois commandes suffisent — mais lorsque vous avez besoin de plus de flexibilité, passez aux sections suivantes.

Installation

apt install acl

Définir des ACL

# Donner lecture à user2 sur un fichier
setfacl -m u:user2:r file.txt

# Donner lecture/écriture à un groupe
setfacl -m g:developers:rw project/

# ACL par défaut (héritage)
setfacl -d -m u:user2:rx /data/

Lire les ACL

getfacl file.txt

Supprimer ACL

setfacl -x u:user2 file.txt  # Retirer user2
setfacl -b file.txt           # Tout supprimer

Cas d'usage concrets

Scénario 1 : partager un projet entre 3 développeurs sans groupe. Chacun a besoin de lire/écrire, mais pas la 4e personne de l'équipe.

# Au lieu de créer un groupe ou utiliser chmod 777
setfacl -m u:alice:rw project/
setfacl -m u:bob:rw project/
setfacl -m u:charlie:rw project/
getfacl project/  # Vérifier

Scénario 2 : héritage d'ACL sur un dossier. Tous les fichiers créés dedans héritent des permissions.

# /data/ est un dossier partagé
setfacl -d -m u:user2:rx /data/
setfacl -d -m g:devops:rw /data/
# Dorénavant, tout fichier créé dans /data/ aura ces permissions
touch /data/new_file.txt
getfacl /data/new_file.txt  # user2 et devops ont accès

Important : les ACL par défaut s'appliquent aux fichiers créés ultérieurement — les fichiers existants ne changent pas. Utile pour les pipelines CI/CD ou les dossiers partagés.

Ces bits spéciaux contrôlent le comportement des exécutables et dossiers partagés.

Sticky bit (t)

Empêche la suppression par n'importe qui. Utilisé sur /tmp/ pour que seul le propriétaire ou root puisse supprimer ses fichiers.

# Vérifier le sticky bit sur /tmp/
ls -ld /tmp/
# drwxrwxrwt 12 root root ...

# Ajouter sticky bit
chmod +t /shared_folder/
# ou chmod 1755 /shared_folder/

# Retirer
chmod -t /shared_folder/

Sans sticky bit, n'importe qui pourrait rm -f le fichier d'un autre dans /tmp/. Cas d'usage : dossiers partagés non sécurisés, répertoires de upload publics.

SUID (Set User ID)

Exécutable s'exécute sous l'UID du propriétaire, pas de l'utilisateur qui le lance. passwd en est l'exemple classique : créé par root, mais chaque utilisateur peut modifier son mot de passe.

# Vérifier SUID sur passwd
ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root ...  <- 's' à la place du 'x' du propriétaire

# Ajouter SUID
chmod u+s /usr/bin/monbinaire
# ou chmod 4755 /usr/bin/monbinaire

# Lister tous les exécutables SUID
find / -perm /4000 2>/dev/null

Risque sécurité : si un exécutable SUID a une faille, l'attaquant obtient les privilèges du propriétaire (souvent root). À minimiser.

SGID (Set Group ID)

Même idée, mais pour le groupe. Exécutable s'exécute sous le GID du propriétaire. Aussi utilisé sur les dossiers pour que les fichiers créés dedans héritent du groupe du dossier.

# SGID sur dossier : héritage du groupe
chmod g+s /data/shared/
# Les fichiers créés héritent du groupe de /data/shared/

# SGID sur exécutable
chmod g+s /usr/bin/monbinaire
# ou chmod 2755

Cas d'usage : dossiers partagés entre une équipe, où tous les fichiers doivent rester "du groupe".

En plus des permissions, Linux permet de marquer un fichier avec des attributs qui restreignent même ce que root peut faire.

Installation

apt install e2fsprogs  # Sur Debian/Ubuntu
yum install e2fsprogs  # Sur RedHat/CentOS

Immutable (+i)

Le fichier ne peut plus être modifié, déplacé, supprimé — même par root (sauf à retirer l'attribut).

# Rendre immutable
chattr +i /etc/passwd

# Essayer de modifier
echo "test" >> /etc/passwd
# bash: /etc/passwd: Operation not permitted

# Lister les attributs
lsattr /etc/passwd
# ----i--------e---- /etc/passwd

# Retirer immutable
sudo chattr -i /etc/passwd

Cas d'usage : fichiers critiques que vous ne voulez jamais modifier accidentellement.

Append-only (+a)

Le fichier ne peut qu'être écrit en fin (append), pas modifié ni tronqué. Utile pour les logs.

# Activer append-only sur un log
chattr +a /var/log/myapp.log

# Ajouter une ligne
echo "new log entry" >> /var/log/myapp.log  # OK

# Essayer de tronquer
> /var/log/myapp.log
# bash: /var/log/myapp.log: Operation not permitted

# Lister
lsattr /var/log/myapp.log
# -----a-------e---- /var/log/myapp.log

Autres attributs courants

• +A : ne met pas à jour atime (accès)
• +d : exclure du backup avec dump
• +e : stocké sur disque avec extent blocks

# Récapitulatif
chattr +i /critical/file           # Immutable
chattr +a /var/log/audit.log       # Append-only
chattr +d /tmp/cache               # Exclude from dump
lsattr -R /etc/                    # Lister récursivement

umask définit les permissions soustraites aux nouveaux fichiers/dossiers. Valeur par défaut souvent 0022.

# Voir umask courant
umask
# 0022

# Créer un fichier
touch test.txt
ls -l test.txt
# -rw-r--r--  (666 - 022 = 644)

# Créer un dossier
mkdir testdir
ls -ld testdir
# drwxr-xr-x  (777 - 022 = 755)

Logique : 0022 retire la permission écriture pour groupe et autres. Donc rwx (7) - 2 = 5 (rx pour groupe/autres).

Changer umask

# Temporaire (cette session)
umask 0077  # Plus restrictif : only owner
touch secret.txt
ls -l secret.txt
# -rw------- (666 - 077 = 600)

# Permanent, ajouter à ~/.bashrc ou ~/.profile
echo "umask 0077" >> ~/.bashrc
source ~/.bashrc

Cas d'usage : serveurs en production (umask 0077), dossiers partagés (umask 0002, permet groupe d'écrire).

Les capabilities décomposent les droits root en capacités granulaires. Au lieu de donner root complet, donnez juste CAP_NET_BIND_SERVICE pour binder les ports < 1024.

Lister capabilities

getcap /usr/bin/ping
# /usr/bin/ping = cap_net_raw+ep

# Chercher tous les exécutables avec capabilities
getcap -r / 2>/dev/null | head -20

Ajouter une capability

Cas réel : vous voulez qu'un service Node.js bind le port 80 sans tourner en root.

# D'abord, créer le binaire/wrapper
# (supposons qu'il soit à /usr/local/bin/myapp)

# Donner la capability
setcap 'cap_net_bind_service=+ep' /usr/local/bin/myapp

# Vérifier
getcap /usr/local/bin/myapp
# /usr/local/bin/myapp = cap_net_bind_service+ep

# Retirer la capability
setcap -r /usr/local/bin/myapp

Capabilities courantes et risques

Meilleure pratique : limiter au strict minimum. CAP_NET_BIND_SERVICE seul est acceptable. Toute capability en "Critique" doit être justifiée.

Audit des capabilities en production

# Chercher les binaires non-root avec capabilities dangereuses
find / -perm /4000 -o -perm /2000 2>/dev/null | xargs getcap 2>/dev/null | grep -E "cap_sys_admin|cap_setuid|cap_dac_override"

Vérifier l'état

getenforce  # Enforcing / Permissive / Disabled
sestatus

Contextes SELinux

ls -Z /var/www/html/
# -rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 index.html

Changer le contexte

chcon -t httpd_sys_content_t /var/www/html/file.html

# Restaurer contexte par défaut
restorecon -v /var/www/html/file.html

Mode permissif temporaire

setenforce 0  # Permissive (log les violations, n'applique pas)
setenforce 1  # Enforcing (applique les règles)

Exemple pratique : Apache sur port custom

# Sans SELinux, Apache peut écrire partout. Avec SELinux :
semanage port -a -t http_port_t -p tcp 8080  # Autoriser port 8080
semanage fcontext -a -t httpd_sys_content_t "/var/www/custom(/.*)?)"  # Custom path
restorecon -R /var/www/custom

1. Principe du moindre privilège

Ne donnez que ce qui est nécessaire. Pas de chmod 777, pas de capabilities inutiles.

# ❌ MAUVAIS
chmod 777 /data/upload
setcap 'cap_sys_admin=+ep' /usr/local/bin/script

# ✅ BON
chmod 755 /data/upload
setfacl -m u:appuser:rw /data/upload  # Seulement appuser
setcap 'cap_net_bind_service=+ep' /usr/bin/nginx  # Minimal

2. Audit des SUID/SGID

Les exécutables SUID/SGID sont des vecteurs d'attaque. Auditez-les régulièrement.

# Trouver tous les SUID
find / -perm /4000 -type f 2>/dev/null > /tmp/suid_baseline.txt

# Comparer avec baseline mensuel
find / -perm /4000 -type f 2>/dev/null > /tmp/suid_current.txt
diff /tmp/suid_baseline.txt /tmp/suid_current.txt

3. sudo vs su : toujours sudo

sudo log les commandes, su donne un shell root. À privilégier.

# ❌ Éviter
su -
apt update

# ✅ Préférer
sudo apt update  # Loggé, auditable

4. Vérifier les capacités des services critiques

# Nginx ne devrait avoir que CAP_NET_BIND_SERVICE
ps aux | grep nginx
# -> pas de -u root, idéalement un user nginx:nginx

getcap /usr/sbin/nginx
# /usr/sbin/nginx = cap_net_bind_service=+ep

5. Immutabilité pour les configs sensibles

# Protéger /etc/shadow et /etc/gshadow
chattr +i /etc/shadow /etc/gshadow

# Vérifier
lsattr /etc/shadow

6. umask sécurisé en production

# Serveur : umask 0077 (pas de permissions groupe/autres)
# Dossier partagé : umask 0002 (groupe peut lire/écrire, autres non)

# Vérifier globalement
grep -r "^umask" /etc/profile* /etc/bash* /home/*/.bashrc

7. Audit ACL et Capabilities mensuels

# Export baseline
getfacl -R / > /backup/acl_baseline.txt
find / -type f -exec getcap {} \; > /backup/cap_baseline.txt

# Comparer après update
getfacl -R / > /tmp/acl_current.txt
diff /backup/acl_baseline.txt /tmp/acl_current.txt

ACL fournissent la granularité pour partager avec plusieurs utilisateurs. Sticky bit/SUID/SGID permettent des exécutables spécialisés et des dossiers sécurisés. Attributs étendus (chattr) renforcent l'immuabilité. Capabilities remplacent les SUID root dangereux. umask configure les permissions par défaut. SELinux ajoute une couche MAC obligatoire en production.

Pour approfondir, consultez :

• SELinux en détail et politiques personnalisées
• CIS Benchmark : audit et conformité Linux
• Sécurisation SSH et clés asymétriques

La sécurité est une couche à la fois. Commencez par les ACL et capabilities, puis progressez vers SELinux en production.