Landlock : confiner un service sans conteneur

Écrire une politique SELinux pour un service qu'on ne connaît qu'à moitié, c'est une demi-journée perdue à traquer des refus dans l'audit log avant de se résoudre à audit2allow et à une règle trop permissive. AppArmor est plus lisible, mais reste une politique système, gérée par root, chargée globalement, qui vit en dehors du binaire qu'elle protège. Les deux exigent des privilèges administrateur et un outillage dédié pour écrire, tester et déployer un profil.

Landlock prend le problème à l'envers. C'est un LSM (Linux Security Module) non privilégié : un processus ordinaire peut réduire ses propres droits d'accès au démarrage, sans droits root, sans policy globale, sans dépendre d'un outil externe pour charger une règle. Ce n'est pas un concurrent de SELinux. C'est une brique différente, avec un périmètre plus étroit et un modèle d'usage radicalement plus simple, disponible dans le noyau depuis 2021 et suffisamment mature aujourd'hui pour du confinement ciblé en production.

Landlock est entré dans le noyau en version 5.13. La mécanique tient en trois appels système : landlock_create_ruleset() crée un jeu de règles vide, landlock_add_rule() y ajoute des droits d'accès associés à des chemins ou des descripteurs de fichiers, et landlock_restrict_self() applique ce jeu de règles au processus courant. Un binaire quelconque, lancé par un utilisateur quelconque, peut faire ces trois appels lui-même avant d'exécuter son code métier.

Le point clé : Landlock ne peut qu'enlever des droits, jamais en accorder. Un processus qui s'auto-restreint via Landlock ne peut pas revenir en arrière, ni pour lui-même ni pour ses enfants. C'est un effet cliquet. Combiné à PR_SET_NO_NEW_PRIVS, ça garantit qu'un processus compromis après coup ne peut pas retrouver l'accès qu'on lui a retiré au démarrage, même s'il obtient une exécution de code arbitraire.

Le modèle d'accès s'est étoffé version après version, sous forme d'ABI numérotées. Chaque ABI ajoute des droits sans casser la compatibilité avec le noyau précédent, ce qui permet à un programme de sonder la version disponible et de dégrader gracieusement ses restrictions :

• ABI 1 (noyau 5.13) : contrôle du système de fichiers proprement dit, exécution, lecture et écriture de fichier, lecture de répertoire, suppression, création de nœuds (fichier, répertoire, socket, fifo, périphérique, lien symbolique).
• ABI 2 (noyau 5.19) : LANDLOCK_ACCESS_FS_REFER, pour autoriser ou bloquer un renommage ou un lien qui traverse deux répertoires soumis à des règles différentes.
• ABI 3 (noyau 6.2) : LANDLOCK_ACCESS_FS_TRUNCATE, pour couvrir la troncature de fichier, un accès qui échappait jusque-là au modèle.
• ABI 4 (noyau 6.7) : première extension réseau, avec LANDLOCK_ACCESS_NET_BIND_TCP et LANDLOCK_ACCESS_NET_CONNECT_TCP. Un processus peut restreindre les ports TCP sur lesquels il a le droit de faire un bind() ou un connect().
• ABI 5 (noyau 6.10) : contrôle des ioctl() sur les périphériques via LANDLOCK_ACCESS_FS_IOCTL_DEV.
• ABI 6 (noyau 6.12) : scoping IPC, avec LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET et LANDLOCK_SCOPE_SIGNAL, pour empêcher un processus confiné de joindre une socket UNIX abstraite ou d'envoyer un signal à un processus hors de son propre domaine Landlock.

Côté ops, ce qu'il faut retenir : le noyau que vous faites tourner détermine ce que vous pouvez restreindre. Un service réseau confiné sur un noyau antérieur à 6.7 ne peut verrouiller que le filesystem, pas les ports sortants. La règle qu'on applique avant de promettre un confinement réseau : on vérifie l'ABI disponible avec landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION), pas la version du noyau annoncée dans un changelog.

Ici, il faut être direct sur un point que beaucoup de billets de blog laissent flou : il n'existe pas, à ce jour, de directive systemd native du type LandlockFilesystem= dans les unités de service. Une proposition (Landlock Config, portée par le mainteneur amont de Landlock lui-même) est en discussion sur le dépôt systemd, et le sujet a fait l'objet d'une présentation dédiée à la conférence All Systems Go! en 2025. Tant que cette proposition n'est pas mergée et disponible dans une version stable, il ne faut pas écrire de configuration qui suppose son existence.

En attendant l'intégration native, systemd offre déjà un socle de confinement via ProtectSystem=, ProtectHome=, NoNewPrivileges= ou SystemCallFilter=, mais aucune de ces directives ne s'appuie sur le LSM Landlock. Pour confiner un service au sens Landlock aujourd'hui, la voie la plus directe consiste à faire porter les règles par le binaire exécuté, via ExecStart=. C'est ce que fait landrun, un outil en Go qui encapsule les appels Landlock et applique les règles avant d'exécuter la commande cible, sans conteneur ni privilège supplémentaire.

En prod, ça donne ça pour un service nginx confiné en lecture seule sur son propre arbre de configuration :

[Service]
ExecStart=/usr/bin/landrun \
  --rox /usr/bin,/usr/lib \
  --ro /etc/nginx,/etc/ssl,/etc/passwd,/etc/group,/etc/nsswitch.conf \
  --rwx /var/log/nginx \
  --rwx /var/cache/nginx \
  --bind-tcp 80,443 \
  /usr/bin/nginx -g 'daemon off;'
NoNewPrivileges=true

Le résultat concret : nginx ne peut ouvrir en écriture que ses logs et son cache, ne peut binder que les ports 80 et 443, et toute tentative d'écrire ailleurs (une exploitation qui tente de déposer un webshell dans /var/www, par exemple) échoue au niveau syscall, avant même d'atteindre la couche applicative. Le droit réseau nécessite un noyau 6.7 ou supérieur, ABI 4 minimum.

Le piège classique, c'est de traiter Landlock comme un SELinux léger. Ce n'est pas le cas, et le confondre avec une politique SELinux complète mène à une fausse impression de sécurité.

Landlock est un mécanisme de confinement volontaire, à la discrétion du processus lui-même. Il n'y a pas de labels, pas de politique système centralisée, pas d'administrateur qui impose une contrainte à un binaire qui ne coopère pas. Un processus qui ne fait jamais l'appel landlock_restrict_self() tourne sans aucune restriction Landlock, point. À l'inverse, SELinux applique sa politique de type enforcement indépendamment de la volonté du binaire audité, avec un modèle MAC (Mandatory Access Control) complet qui couvre les capabilities, les transitions de contexte, l'étiquetage des objets et un audit trail centralisé dans le journal AVC.

Le contrôle réseau de Landlock, même à jour sur ABI 4, reste limité au TCP bind() et connect(). Pas de filtrage par adresse IP source, pas de contrôle du trafic UDP, pas d'équivalent aux règles de pare-feu ou aux politiques réseau qu'on retrouve dans un durcissement complet d'un socle Docker via des network policies ou des règles nftables dédiées. Landlock ne remplace ni un pare-feu, ni seccomp pour le filtrage d'appels système hors filesystem et réseau, ni la gestion fine des capabilities Linux.

Ce que Landlock apporte réellement, c'est une couche de confinement en profondeur, peu coûteuse à intégrer, qui vient s'ajouter aux mécanismes existants plutôt que les remplacer. Un binaire qui s'auto-restreint au démarrage avec Landlock, tourne sous des capabilities minimales, et reste soumis à un profil seccomp, ferme trois portes différentes avec trois mécanismes qui ne partagent pas la même surface d'échec.

Landlock est pertinent pour un service exposé dont le périmètre de fichiers et de ports est connu et stable : un serveur web statique, un reverse proxy, un worker qui ne doit toucher qu'une poignée de répertoires. C'est particulièrement adapté aux binaires qu'on ne peut pas faire tourner dans un conteneur pour des raisons de performance ou d'intégration système, et où le coût d'une politique SELinux complète serait disproportionné par rapport au gain.

Ce n'est pas une réponse à un besoin de politique centralisée, auditée et imposée par un tiers : sur ce terrain-là, SELinux ou AppArmor restent les bons outils, en particulier sur des postes ou des infrastructures multi-tenant où on ne contrôle pas le code qui tourne. Et tant que la directive systemd native n'est pas mergée, il faut accepter la dette d'exploitation d'un wrapper supplémentaire dans ExecStart=, avec sa propre gestion de version et de compatibilité de noyau.

La recommandation qu'on donne systématiquement avant d'ajouter du confinement applicatif : vérifier d'abord la version d'ABI Landlock disponible sur le noyau en production, cartographier précisément les fichiers et les ports dont le service a réellement besoin, puis superposer Landlock aux mécanismes systemd et seccomp déjà en place plutôt que d'en faire l'unique ligne de défense. C'est le même principe qui structure un audit sécurité Linux sérieux : plusieurs mécanismes indépendants, pas un seul mécanisme jugé suffisant.

Sur les infrastructures qu'on opère, le hardening d'un service ne s'arrête jamais à un seul dispositif. Si vous cherchez à réduire la surface d'attaque de vos services Linux sans tout faire reposer sur une conteneurisation lourde, on peut auditer votre socle système et prioriser les durcissements qui comptent réellement.

• Landlock : unprivileged access control (documentation noyau Linux) : description officielle du modèle, des appels système et de la progression des ABI.
• landlock(7), page de manuel : référence complète des droits d'accès par version d'ABI.
• Landlock Access Controls Extended To Networking With Linux 6.7 (Phoronix) : couverture technique de l'ajout du contrôle TCP en ABI 4.
• Landlock news #5 (landlock.io) : annonce du scoping IPC (sockets UNIX abstraites, signaux) introduit avec l'ABI 6 en noyau 6.12.
• Landlock Config, pull request #39174 (dépôt systemd) : état actuel, non mergé, de l'intégration native de Landlock dans les unités systemd.