La restriction des espaces de noms non privilégiés (unprivileged user namespaces) constitue un changement de posture majeur dans le durcissement Linux récent. Ubuntu 24.04 LTS active par défaut, via AppArmor, une politique qui limite les capacités accessibles aux processus non privilégiés dans ces espaces de noms.
Ce réglage casse potentiellement des outils courants : navigateurs exécutant leur sandbox, agents de développement, conteneurs lancés sans droits root. Traiter ces exceptions au cas par cas, plutôt que désactiver globalement la protection, définit la ligne de crête entre sécurité et exploitabilité du système.
Confinement AppArmor et espaces de noms : ajuster sans désarmer
Un profil AppArmor actif ne signifie pas que toutes les applications tournent en mode confiné. Sur Ubuntu 24.04, seuls les programmes disposant d’un profil chargé et appliqué bénéficient réellement de restrictions. Les autres fonctionnent en mode non confiné, même si le module est présent dans le noyau.
Le problème se pose concrètement avec les navigateurs (Chromium, Firefox en Snap), les runtimes de conteneurs comme runc et containerd, ou les environnements de développement qui créent des sandboxes via des espaces de noms utilisateur. La restriction par défaut d’Ubuntu 24.04 bloque les capacités réseau ou de montage dans ces espaces, provoquant des échecs silencieux ou des crashs au lancement.
La bonne approche consiste à créer un profil AppArmor dédié par application qui nécessite ces fonctionnalités. Un profil accorde les capacités strictement requises (par exemple cap net_admin pour un outil réseau dans un namespace) sans toucher au réglage global. Les articles publiés sur la rubrique sécurité de Hebdo Linux détaillent régulièrement ce type de configuration granulaire.
Désactiver kernel.unprivileged_userns_clone revient à supprimer une couche de défense entière. Mieux vaut maintenir la restriction active et gérer les exceptions une par une, en documentant chaque profil ajouté dans votre gestionnaire de configuration.
Cycle de vie des distributions : cartographier les échéances de support
Considérer « Linux » comme un environnement homogène mène à des angles morts en gestion de vulnérabilités. Chaque distribution suit son propre calendrier. Ubuntu 24.04 LTS bénéficie d’une maintenance de sécurité standard annoncée jusqu’en mai 2029, avec des extensions possibles via les offres ESM et Legacy. Une Fedora ou une Arch rolling-release impose un rythme de mise à jour radicalement différent.
Un parc mixte (serveurs sous RHEL, postes de développement sous Ubuntu, conteneurs Alpine) exige un inventaire précis des dates de fin de support. Sans cet inventaire, des noyaux obsolètes restent en production sans que personne ne s’en aperçoive.
Trois pratiques concrètes pour piloter ce risque :
- Maintenir un registre centralisé (CMDB ou simple tableur) associant chaque machine à sa distribution, sa version de noyau et sa date de fin de support sécurité.
- Configurer des alertes automatiques (cron + script ou outil de gestion de parc) qui signalent l’approche d’une fin de maintenance, au moins six mois avant l’échéance.
- Tester les montées de version majeures dans un environnement de staging avant de les appliquer en production, en validant que les profils AppArmor ou SELinux existants restent fonctionnels.
Vulnérabilités noyau et comptes locaux : le risque du poste partagé
Les failles du noyau ne nécessitent pas toujours un accès distant pour être exploitées. Un utilisateur local peu privilégié peut tirer parti d’une vulnérabilité d’élévation de privilèges pour obtenir un accès root. Sur les serveurs multi-utilisateurs, les machines de développement partagées ou les postes en libre accès, chaque compte local superflu élargit la surface d’attaque.
La réduction des comptes passe par un audit régulier du fichier /etc/passwd et des groupes associés. Les comptes de service inutilisés (créés par d’anciens paquets désinstallés) doivent être verrouillés ou supprimés. Pour les comptes humains, le principe du moindre privilège s’applique : un développeur n’a pas besoin d’appartenir au groupe sudo sur un serveur de production.
L’application rapide des correctifs noyau recommandés par le fournisseur de la distribution reste la première ligne de défense. Sur les systèmes où le redémarrage pose un problème de disponibilité, les solutions de live patching permettent de corriger le noyau en mémoire sans interruption de service.
Conteneurs Linux : un confinement distinct de celui de l’hôte
Les conteneurs partagent le noyau de la machine hôte. Cette architecture signifie qu’une vulnérabilité noyau exploitable depuis un conteneur compromet potentiellement tout l’hôte. La frontière du conteneur n’est pas une frontière de sécurité suffisante pour des charges non fiables sans couches supplémentaires.
Sur Ubuntu 24.04, des ajustements AppArmor ont directement touché runc et containerd. Les profils par défaut peuvent bloquer des opérations légitimes (montage de volumes, accès à certains devices) ou, à l’inverse, ne pas restreindre suffisamment un conteneur exécutant du code tiers.
Nous recommandons de tester systématiquement les mises à jour de profils AppArmor dans l’environnement conteneurisé réel avant de les déployer. Un pipeline CI qui lance les conteneurs critiques après chaque mise à jour de l’hôte détecte les régressions avant qu’elles n’atteignent la production.
Deux mesures complémentaires renforcent le confinement :
- Activer les profils seccomp spécifiques au runtime utilisé (Docker, Podman, containerd), qui filtrent les appels système autorisés depuis le conteneur.
- Utiliser des espaces de noms réseau dédiés par groupe de conteneurs, combinés à des règles nftables ou iptables qui limitent les communications inter-conteneurs au strict nécessaire.
- Exécuter les conteneurs avec un utilisateur non root à l’intérieur du conteneur (directive
USERdans le Dockerfile), même lorsque le runtime supporte le rootless mode côté hôte.
La sécurité d’un environnement Linux ne se résume pas à une checklist appliquée une fois. Les profils de confinement, les calendriers de support et les comptes locaux évoluent avec chaque mise à jour de distribution, chaque ajout d’outil et chaque changement d’équipe. Intégrer ces vérifications dans les routines d’exploitation (revues trimestrielles, pipelines CI, alertes de fin de support) transforme le durcissement ponctuel en posture de sécurité durable.
