Appliquer Landlock sur Linux

 (blog.prizrak.me)
1 points par GN⁺ 2025-12-01 | 1 commentaires | Partager sur WhatsApp
  • Landlock est une API de sécurité Linux qui oblige les applications à déclarer explicitement les ressources auxquelles elles peuvent accéder, afin d’exécuter une auto-sandboxing au niveau du noyau.
  • Plus simple que les solutions existantes SELinux ou AppArmor, il permet de créer et d’appliquer des politiques au runtime sans privilèges d’administrateur.
  • Les politiques définissent des listes blanches (allowlist) explicites de fichiers, répertoires et ports accessibles, avec une restriction hiérarchique permettant de renforcer progressivement la sécurité.
  • Des bindings sont disponibles pour Rust, Go, Haskell, etc., ce qui permet d’implémenter un contrôle d’accès fin dans des applications GUI, serveurs ou processus desktop variés.
  • Dans l’écosystème de sécurité Linux, c’est considéré comme un outil de sandboxing sans privilège, simple et pratique, et il est vu comme un futur composant clé du renforcement de la sécurité desktop.

Présentation de Landlock

  • Landlock est une API qui permet aux applications Linux de déclarer explicitement les ressources auxquelles elles peuvent accéder
    • Sur le même principe qu’unveil() et pledge() d’OpenBSD, elle applique le principe : « autoriser uniquement les ressources nécessaires et bloquer le reste »
  • Il fournit une couche de défense orientée développeur, plus simple à comprendre et intégrer que les mécanismes Linux existants
  • Son objectif est de promouvoir l’adoption de Landlock en déclarant explicitement les accès.

Fonctionnement

  • Forme de Linux Security Module (LSM), disponible depuis Linux 5.13
  • Contrairement à SELinux ou AppArmor, il applique une restriction temporaire par processus (transient restriction)
    • La politique est créée à l’exécution et ne s’applique qu’au thread courant et à ses processus enfants ; elle disparaît quand le processus se termine
  • Composants de la politique
    1. Handled accesses : catégories d’opérations à restreindre (ex. : lecture/écriture du système de fichiers)
    2. Access grants : liste explicite des objets autorisés
  • Exemple de politique
    • lecture seule de /home/user
    • lecture/écriture sur /tmp
    • autorisation de la liaison du port 2222
  • Lorsque landlock_restrict_self() est appelé, le thread et ses processus enfants entrent dans une zone de restriction permanente
    • La restriction est irréversible ; jusqu’à 16 couches peuvent être imbriquées
    • Une couche enfant peut restreindre davantage les accès, mais les permissions retirées dans une couche supérieure ne peuvent pas être rétablies
  • Approche non privilégiée : une application classique peut se sandboxer elle-même
  • Grâce à la gestion de version ABI, le comportement reste fonctionnel dans la plage supportée par les anciens noyaux
  • C’est un Stackable LSM, donc compatible avec un usage conjoint de SELinux ou AppArmor

Pourquoi l’utiliser

  • Adapté aux applications avec des modèles d’accès aux fichiers prévisibles
    • ex. : limiter un serveur web à l’accès seulement à /var/www/html et /tmp
  • Pas d’intervention d’administrateur ni de réglage global système requis, la politique peut être définie directement dans le code
  • Utilisable sans élévation de privilèges, intégrable facilement à la plupart des programmes
  • Des bindings existent pour Rust, Go, Haskell, et de nombreux projets wrapper de type unveil sont disponibles
  • La bibliothèque C officielle n’existe pas encore, mais plusieurs implémentations non officielles sont utilisables
  • Dans les exemples Rust, /usr, /etc, /dev sont en lecture seule, tandis que /home et /tmp sont en lecture/écriture

État actuel et nécessité du sandboxing Linux

  • La hausse d’utilisation de Linux s’accompagne d’une hausse des malwares ciblant les postes de travail
  • La sécurité relative de Linux ne vient pas d’une sûreté structurelle, mais surtout de sa part de marché et des barrières techniques
  • Limites des distributions générales
    • Exécution possible de binaires non fiables
    • Exécution directe de scripts téléchargés sur Internet
    • Utilisation de sudo sans mot de passe
    • Les applications ordinaires peuvent accéder à des fichiers sensibles dans $HOME
    • Surveillance possible des frappes clavier en environnement X11
    • Liaison arbitraire de ports possible

Limites des outils de sécurité existants

  • Containerization (Docker, Podman) : adapté à l’isolation des services, mais peu adapté aux applications desktop ; des cas existent où l’option --privileged neutralise l’isolation
  • Flatpak / Snap : adaptés aux apps GUI, mais les permissions sont souvent trop larges et peu adaptés aux outils CLI
  • Firejail : nécessite des profils par application et un appel explicite à chaque lancement

Limites côté développeur des mécanismes existants

  • seccomp : puissant mais configuration complexe, et l’approche en liste noire est fragile
  • SELinux : puissant mais complexe et exige des politiques administratives ; de nombreuses distributions sont désactivées par défaut
  • AppArmor : plus simple que SELinux mais demande tout de même des profils administrateur, et peut être désactivé sur certaines distributions

Points forts de Landlock

  • Sans privilège, centré application, facile à intégrer, refus par défaut (deny-by-default)
  • Large support depuis Linux 5.13, avec maintien de la compatibilité ascendante/descendante
  • Il n’est pas parfait, mais il comble un vide en tant qu’outil de sandboxing simple, indépendant et non privilégié

Potentiel d’adoption de Landlock

  • Pour les processus daemon à longue exécution avec privilèges élevés, il est possible de limiter leur surface d’accès via Landlock
  • Les lecteurs PDF, visionneuses d’images, navigateurs web, traitements de texte peuvent être limités aux seuls fichiers ouverts
  • Les serveurs FTP/HTTP peuvent être restreints aux seuls fichiers nécessaires
    • Exemple : même si un attaquant obtient un shell sur nginx exécuté en root, il ne peut pas lire les fichiers hors politique
  • Avec l’introduction d’une proposition Supervisor, un système de permissions de type Android pourrait être implémenté sur Linux desktop
    • Associé à un système de permissions GUI et de stockage, une expérience utilisateur plus sûre devient possible

Fonctionnalités en cours de développement dans Landlock

  • Supervise Mode : décision interactive d’autorisation/refus des accès depuis l’espace utilisateur, proche des invites de permission Android
  • Socket Restrictions : contrôle fin des types de sockets et des ports qu’un processus peut utiliser
  • LANDLOCK_RESTRICT_SELF_TSYNC : propage la restriction à tous les threads du processus
  • LANDLOCK_ADD_RULE_QUIET : supprime les messages de journal d’audit pour certains objets
  • LANDLOCK_ADD_RULE_NO_INHERIT : empêche l’héritage des permissions d’un répertoire parent vers ses enfants, pour affiner le contrôle du système de fichiers

Résumé

  • Landlock est un mécanisme de sandboxing par défaut de type deny-by-default, simple et basé sur l’absence de privilèges
  • Facile à comprendre et à intégrer, il a un fort potentiel pour améliorer la sécurité de Linux desktop et des applications
  • Les développeurs peuvent renforcer le niveau de sécurité en appliquant directement Landlock à leurs applications

À lire aussi

1 commentaires

 
GN⁺ 2025-12-01
Avis Hacker News
  • J’ai utilisé Landlock pour bloquer de la télémétrie indésirable
    J’ai écrit un petit programme en C pour n’autoriser l’écoute que sur un seul port précis, et bloquer toutes les autres connexions réseau
    Je me suis appuyé sur l’exemple sandboxer.c, en ne touchant pas aux restrictions d’accès aux fichiers et en ne contrôlant que le réseau
    Les connexions bloquées apparaissent dans dmesg, probablement grâce à la fonction d’audit
    Cet outil fonctionne en mode utilisateur non privilégié et marche aussi très bien dans un conteneur, sans configuration de pare-feu
    En revanche, je ne pense pas qu’il soit adapté pour arrêter complètement un programme malveillant
    • Je me demande si tu pourrais partager le code source
  • Landlock n’est pas parfait
    En regardant l’issue #28 et le fil de discussion associé, il y a un problème : les règles de sandbox ne peuvent pas référencer des répertoires inexistants
    Par exemple, si on ajoute une règle alors que ~/.ssh n’existe pas encore, l’accès ne sera pas bloqué même si le répertoire est créé plus tard
    Autrement dit, cela peut créer une faille de sécurité
  • Je suis en train d’essayer de sandboxer des jeux itch.io avec bwrap
    Les faire tourner avec le minimum de privilèges est assez délicat
    « Microlandia » ne se lance pas, mais d’autres jeux Unity fonctionnent bien
    J’espère qu’il y aura davantage d’outils basés sur Landlock pour faciliter ce genre de choses
  • Je me demande quel est l’état du support de Landlock dans les runtimes de conteneurs
    Les CRI semblent vouloir définir leur propre interface, mais elles auront forcément toujours du retard sur le support du noyau
    Je doute que la plupart des responsables d’infrastructure maintiennent des politiques de sandbox par application
    Il me semble plus réaliste que les applications utilisent directement Landlock
    • En mentionnant les issues runc et runtime-spec,
      on explique que si le runtime se contente de laisser passer les appels système, cela pose le problème de devoir faire confiance à l’application pour s’enfermer elle-même
    • Je pense que Landlock n’a pas été conçu à l’origine pour les runtimes de conteneurs, mais pour un autre usage
  • En tant que développeur de dispositifs médicaux, cette approche est très bienvenue
    En interne, nous utilisons une API similaire pour la gestion des processus critiques
    Ce type de recherche sera aussi d’une grande aide dans les secteurs réglementés
  • Dire qu’il n’existe « pas de bibliothèque C officielle » paraît étrange
    S’il s’agit d’une fonctionnalité du noyau, on s’attendrait naturellement à ce qu’une API C existe d’abord, donc je me demande pourquoi ce n’est pas le cas
    • L’interface de base du noyau, c’est syscall(uapi)
      libc n’est qu’une couche au-dessus, et beaucoup d’appels système existent encore sans wrapper dans libc
    • Ici, on parle de bibliothèques C standard comme glibc ou musl
      On peut aussi créer les en-têtes soi-même et appeler directement via la macro _syscallN
    • L’absence d’API C n’est pas vraiment un gros problème
      On peut utiliser un petit wrapper comme landbox,
      et Rust ou Go peuvent aussi exposer une FFI C
      L’exemple sandboxer.c du noyau suffit largement comme référence
    • L’essentiel est déjà documenté dans la page man7
    • Les développeurs du noyau ne construisent pas directement de logiciels userland, d’où l’absence d’API C
  • Il faut faire attention au fait que Landlock ne restreint que les sockets TCP, et pas les sockets UDP ni raw
    • Cela ressemble à une assez grosse faille de sécurité. Je me demande pourquoi
    • Les sockets raw nécessitent des privilèges, et on peut aussi faire du blocage par UID avec iptables
      Ce n’est pas la même chose que Landlock, mais cela peut être complémentaire
    • Malgré tout, ça donne l’impression d’un trou assez important
    • C’est une contrainte étrange, mais bon à savoir
  • Il est intéressant que Landlock ait ajouté un nouveau syscall au lieu d’utiliser une configuration via /sys
    C’est probablement lié au principe de moindre privilège
    Je me demande aussi s’il est possible de bloquer les syscalls Landlock avec seccomp
    Si une ancienne politique seccomp n’inclut pas les numéros de Landlock, est-ce qu’on ne risque pas un SIGSYS ?
    • D’autres LSM évoluent eux aussi progressivement vers des interfaces basées sur des syscalls
      Les API fondées sur le système de fichiers comportent beaucoup de footguns, et pour le contrôle d’accès basé sur dirfd, un syscall est plus adapté
      Un filtre seccomp bien conçu renverra -ENOSYS, ce qui ressemblera simplement à un « non pris en charge »
    • On peut restreindre les syscalls Landlock avec seccomp, mais l’intérêt pratique est limité
      Landlock ne fait que réduire des privilèges existants, il n’en accorde pas de nouveaux
  • Je commence tout juste à m’intéresser à la sécurité Linux
    Je me prépare à quitter complètement macOS pour passer à Linux, et je me demande dans quelle mesure Landlock peut aider contre les malwares
    Par exemple, j’aimerais créer un environnement qui refuse automatiquement l’accès à ~/.ssh
    Et je voudrais aussi savoir si on peut en faire un lanceur d’applications
    • Le modèle de menace de Landlock n’est pas le malware en lui-même, mais les failles d’exécution de code dans des applications légitimes
      Il sert à ce qu’une application limite elle-même les privilèges dont elle n’a pas besoin, afin qu’un attaquant ne puisse pas prendre le contrôle du système
    • Pour bloquer l’accès à ~/.ssh, il faut plutôt un modèle MAC comme AppArmor ou SELinux
      Landlock est utile lorsqu’une application se restreint elle-même ou restreint ses processus enfants
      Par exemple, npm pourrait limiter un script post-install au seul répertoire de build
      C’est une API destinée à être utilisée directement par les développeurs d’applications, à la manière de pledge sur OpenBSD
      Mais l’écosystème Linux étant fragmenté, l’adoption sera lente
      En attendant, la forme la plus réaliste reste celle de wrappers ou de lanceurs
    • Il faut soit que le gestionnaire de paquets définisse une politique pour les scripts de build, soit que l’utilisateur passe par un wrapper
      Au final, cela n’est efficace que lorsque le programme connaît lui-même ses propres privilèges
    • C’est presque exactement le même concept que le sandboxing sur macOS et iOS
      L’application liste en liste blanche les ressources nécessaires au démarrage, puis bloque tout le reste
      Ce n’est pas destiné à se défendre contre les programmes malveillants, mais à protéger son propre processus
  • Dire qu’il n’existe « pas de bibliothèque C officielle » me fait sourire
    Il y a déjà des syscalls dans la bibliothèque standard, donc faut-il vraiment une bibliothèque séparée ?
    La page man7 existe déjà
    Je me demande si cela signifie simplement qu’on veut une couche d’abstraction
    • Comme libc s’occupe de la gestion des numéros de syscall et de certains effets de bord,
      il est surprenant que glibc ne fournisse pas encore l’interface Landlock
      C’est peut-être à cause de questions de compatibilité hors Linux