Linux avancé : permissions et sécurité du système

Cette page approfondit Ubuntu Server : actions après l’installation et complète SSH : durcissement du serveur et Pare-feu. Principe directeur : moindre privilège.

Permissions classiques

ls -l fichier
# -rw-r----- 1 alice www-data 1204 janv. 15 10:30 fichier

Champ	Sens
`-`	Type (`-` fichier, `d` dossier, `l` lien)
`rw-`	Droits du propriétaire
`r--`	Droits du groupe
`---`	Droits des autres

Droit	Fichier	Dossier
`r` (4)	Lire	Lister le contenu
`w` (2)	Modifier	Créer, renommer, supprimer des entrées
`x` (1)	Exécuter	Traverser (accéder aux éléments)

chmod 640 fichier                 # rw-r-----
chmod u=rwx,g=rx,o= script.sh
chmod -R g+rX dossier/            # X : exécution seulement pour les dossiers (et fichiers déjà exécutables)
chown alice:www-data fichier
chown -R alice: dossier/
find /srv/site -type d -exec chmod 750 {} +
find /srv/site -type f -exec chmod 640 {} +

Un dossier a besoin de x pour être traversé : sans x sur un dossier parent, on n’atteint pas ses fichiers, même lisibles (namei -l /chemin/complet montre les droits de chaque niveau).

`umask`

umask                              # 0022 : fichiers 644, dossiers 755
umask 027                          # fichiers 640, dossiers 750

Le umask retire des droits aux fichiers nouvellement créés. Pour un service : UMask=0027 dans l’unité systemd.

Bits spéciaux

Bit	Fichier	Dossier	Exemple
setuid (`s` chez le propriétaire)	S’exécute avec les droits du propriétaire	Sans effet	`/usr/bin/passwd`
setgid (`s` chez le groupe)	S’exécute avec les droits du groupe	Les nouveaux fichiers héritent du groupe du dossier	Dossier partagé
sticky (`t`)		Seul le propriétaire d’un fichier peut le supprimer	`/tmp`

chmod g+s /srv/projet              # fichiers créés dans le dossier appartiennent au groupe du dossier
chmod +t /srv/depot                # sticky
sudo find / -xdev -perm -4000 -type f 2>/dev/null        # programmes setuid : à connaître et à surveiller

Un programme setuid root inconnu est un signal d’alerte : il donne les droits de root à celui qui l’exécute.

ACL : droits fins

Les ACL (listes de contrôle d’accès) donnent des droits à des utilisateurs ou groupes supplémentaires sans changer le propriétaire ni le groupe.

sudo apt install acl
setfacl -m u:alice:rwx /srv/projet
setfacl -m g:equipe:rX /srv/projet
setfacl -R -m u:alice:rwx /srv/projet                    # récursif
setfacl -d -m g:equipe:rwX /srv/projet                   # ACL PAR DÉFAUT : appliquée aux futurs fichiers
setfacl -x u:alice /srv/projet                           # retirer
setfacl -b /srv/projet                                   # tout retirer
getfacl /srv/projet

ls -l affiche un + après les droits lorsqu’une ACL existe (drwxr-x---+). Les ACL par défaut (-d) règlent le cas des dossiers partagés où les nouveaux fichiers doivent être accessibles à un groupe.

Capabilities : divisions des droits de root

Plutôt que d’exécuter un programme en root, on lui accorde seulement la capacité nécessaire :

getcap -r /usr/bin 2>/dev/null
sudo setcap cap_net_bind_service=+ep /usr/bin/node           # écouter sur un port < 1024 sans être root
sudo setcap -r /usr/bin/node                                  # retirer

Pour un service systemd : AmbientCapabilities=CAP_NET_BIND_SERVICE et NoNewPrivileges=true (systemd : durcissement d’un service). Une capacité accordée à node s’applique à tous les programmes Node.js exécutés : préférer l’option de l’unité systemd, ou un reverse proxy sur les ports 80 et 443.

Attributs de fichier : `chattr`

sudo chattr +i /etc/resolv.conf       # immuable : modification et suppression impossibles, même par root
sudo chattr +a /var/log/audit.log     # ajout seul
lsattr /etc/resolv.conf
sudo chattr -i /etc/resolv.conf

Protège un fichier critique contre une modification accidentelle ; pense à retirer +i avant une mise à jour légitime (cause fréquente d’erreurs de mise à jour inexplicables).

`sudo`

sudo visudo                                   # édition sûre (vérifie la syntaxe)
sudo visudo -f /etc/sudoers.d/deploiement     # fichier dédié
sudo -l                                       # ce que l'utilisateur courant peut faire
sudo -u postgres psql                         # agir comme un autre utilisateur
sudo journalctl -t sudo                       # journal des usages de sudo (ou /var/log/auth.log)

/etc/sudoers.d/deploiement :

Cmnd_Alias RELANCE = /usr/bin/systemctl restart monapp, /usr/bin/systemctl status monapp
deploy ALL=(root) NOPASSWD: RELANCE
%admins ALL=(ALL:ALL) ALL
Defaults:deploy !requiretty
Defaults timestamp_timeout=5

Règle	Conseil
Commandes précises regroupées par `Cmnd_Alias`	Éviter `ALL` pour les comptes de service
`NOPASSWD`	À limiter à des commandes exactes (jamais `NOPASSWD: ALL` pour un compte exposé)
Éditer avec `visudo`	Une erreur de syntaxe peut verrouiller `sudo`
Fichiers dans `/etc/sudoers.d/` (`chmod 440`)	Facilite la gestion ; noms sans point ni `~`

Sur Ubuntu 26.04, sudo est fourni par sudo-rs : la syntaxe usuelle des fichiers sudoers est prise en charge, mais certaines options avancées peuvent différer ; tester avec sudo visudo -c et une session de secours ouverte.

AppArmor

AppArmor confine des programmes selon des profils (fichiers accessibles, capacités, réseau). Actif par défaut sur Ubuntu.

sudo aa-status                                  # profils chargés, en mode « enforce » ou « complain »
sudo apt install apparmor-utils apparmor-profiles
sudo aa-complain /usr/sbin/nginx                # mode apprentissage : journalise sans bloquer
sudo aa-enforce /usr/sbin/nginx                 # mode application
sudo aa-logprof                                 # propose des mises à jour de profil depuis les journaux
sudo journalctl -k | grep -i 'apparmor="DENIED"'
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx    # recharger un profil

Un programme qui échoue avec « Permission denied » alors que les droits Unix sont corrects est souvent bloqué par AppArmor : chercher apparmor="DENIED" dans journalctl -k. Ne pas désactiver AppArmor : passer le profil en complain, corriger, puis revenir en enforce.

Audit : `auditd`

sudo apt install auditd
sudo auditctl -w /etc/passwd -p wa -k identite                 # surveiller écritures et changements d'attributs
sudo auditctl -w /etc/sudoers.d/ -p wa -k sudo
sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k commandes-root
sudo ausearch -k identite --start today
sudo aureport --auth --summary
sudo auditctl -l

Règles permanentes dans /etc/audit/rules.d/ (puis sudo augenrules --load). L’audit produit beaucoup de données : cibler les fichiers et actions sensibles.

Comptes et authentification

id alice
getent passwd alice
sudo adduser alice
sudo usermod -aG docker alice                # le groupe docker équivaut à des droits root : à réserver aux comptes de confiance
sudo passwd -l alice                         # verrouiller le mot de passe
sudo usermod -e 2026-12-31 alice             # expiration du compte
sudo chage -l alice                          # politique de mot de passe
sudo chage -M 90 -W 14 alice
last -n 10                                   # dernières connexions
sudo lastb -n 10                             # échecs de connexion
who; w
sudo faillock --user alice                   # verrouillages (PAM)

Pratique	Raison
Un compte par personne	Traçabilité
Pas de connexion directe en `root` (SSH : `PermitRootLogin no`)	Voir SSH : durcissement
Comptes de service sans shell (`/usr/sbin/nologin`)	`sudo adduser --system --group --shell /usr/sbin/nologin monapp`
Retirer les comptes inutilisés	Réduire la surface d’attaque
Mots de passe forts ou clés uniquement	Voir SSH : clés

Les groupes docker et lxd donnent de fait les droits de root sur la machine : ne pas y ajouter d’utilisateur qui ne doit pas être administrateur (Docker : installation).

Mises à jour de sécurité

sudo apt install unattended-upgrades needrestart
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade --dry-run -d
cat /var/run/reboot-required 2>/dev/null
sudo needrestart -r l                         # services à redémarrer après mise à jour de bibliothèques
apt list --upgradable

Un noyau ou une bibliothèque mise à jour demande souvent un redémarrage (ou celui des services concernés : needrestart). Ubuntu Pro propose le Livepatch (correctifs du noyau sans redémarrage) : voir Noyau et démarrage.

Auditer la configuration

sudo apt install lynis
sudo lynis audit system
sudo cat /var/log/lynis-report.dat | grep -E "^(warning|suggestion)"
sudo ss -tlnp                                  # services exposés
sudo find / -xdev -type f -perm -0002 2>/dev/null | head      # fichiers modifiables par tous
sudo find / -xdev -nouser -o -nogroup 2>/dev/null | head      # fichiers orphelins

Lynis donne une liste d’améliorations classées ; les examiner une par une plutôt que de tout appliquer.

Dépannage

Symptôme	Piste
`Permission denied` malgré des droits corrects	Droit `x` manquant sur un dossier parent (`namei -l`), ACL, AppArmor, SELinux-like ailleurs
Fichiers créés avec les mauvais droits	`umask`, setgid et ACL par défaut sur le dossier
`sudo: unable to resolve host`	Nom d’hôte absent de `/etc/hosts`
`sudo` verrouillé après modification	Erreur dans `sudoers` : garder une session `root` ouverte, `visudo -c`
Un programme ne peut pas ouvrir un port < 1024	`setcap cap_net_bind_service`, ou un reverse proxy
`chattr` : `Operation not permitted` sur un fichier	Attribut immuable : `lsattr`, `chattr -i`
Le service échoue sous AppArmor	`journalctl -k \| grep DENIED`, `aa-complain` puis ajustement du profil
`audit` remplit le disque	Règles trop larges, rotation (`/etc/audit/auditd.conf`)

Ubuntu 24.04 et 26.04 : différences à connaître

Sur 26.04, sudo est fourni par sudo-rs (l’ancienne version devient sudo.ws) : les usages courants sont identiques, certaines directives avancées de sudoers demandent une vérification. AppArmor, auditd et acl sont disponibles sur les deux versions.

Pour aller plus loin

Manuels : man chmod, man acl, man capabilities, man sudoers, man apparmor, Documentation Ubuntu : AppArmor
Suite : Journaux et diagnostic de performance