Selon le blog de SEKOIA, cet article explore Landlock en tant que mécanisme de sécurité et comme source de données utiles à l’ingénierie de détection.

Landlock (Linux) comme télémétrie pour la détection

Contexte

L’équipe Sekoia TDR (Threat Detection & Research) s’intéresse à Landlock, un Linux Security Module (LSM) introduit dans le noyau Linux 5.13. Landlock permet de créer des sandbox applicatives (contrôles d’accès “par processus”), applicables à des processus privilégiés ou non, en complément des mécanismes d’accès systèmes existants (défense en profondeur).

Pourquoi c’est intéressant pour la détection

Même si Landlock est avant tout un mécanisme de durcissement, il devient aussi une source de télémétrie utile pour les SOC :

  • Les refus d’accès générés par Landlock peuvent être journalisés via auditd.
  • L’intégration “complète” dans le système Audit est annoncée à partir du noyau Linux 6.15.
  • Point clé : lorsqu’un évènement Landlock est généré, cela signifie que le binaire a été compilé/configuré pour faire remonter ce type de violation. Donc :
    • c’est souvent très discriminant (faible bruit),
    • potentiellement peu de faux positifs si la sandbox est bien pensée.

Les logs Landlock contiennent des champs structurants comme :

  • domain (identifiant du domaine Landlock / sandbox)
  • blockers (type de restriction violée : ex. fs.make_reg, net.connect_tcp)
  • détails du syscall (openat, connect), chemin ciblé (path=...), IP/port (daddr, dest), etc.

Exemples montrés dans l’article

1) Règles fichiers (filesystem)

Exemple : sandbox qui autorise lecture seule sur / et lecture/écriture sur /tmp.

  • Une tentative d’écriture hors /tmp déclenche un Landlock denial (audit type 1423), typiquement avec blockers=fs.make_reg et un EACCES.

2) Règles réseau

Exemple : autoriser uniquement des connexions TCP vers 443.

  • Une tentative curl http://... (port 80) génère un refus Landlock avec blockers=net.connect_tcp, dest=80.

3) Cas d’usage “vulnérabilité dans un exécutable”

Exemple pédagogique : serveur web vulnérable à la lecture de fichier arbitraire via paramètre file.

  • Landlock limite l’accès à /var/lib/htdocs.
  • Une tentative de lecture type /etc/passwd est bloquée et journalisée, ce qui permet une alerte côté SOC.

4) XZ Utils & Landlock

Le billet revient sur le contexte XZ / CVE-2024-3094 : l’attaquant avait empêché la compilation de la partie Landlock “avec un point” (détail notable). Ils illustrent ensuite un scénario LD_PRELOAD : une bibliothèque malveillante tente d’exécuter ls /tmp.

  • Avec une version de XZ compilée avec Landlock, l’exécution est bloquée et loguée.
  • Avec une version sans Landlock, l’exécution passe.

Détection (exemple Sigma proposé)

Le billet propose une règle simple basée sur la présence de champs spécifiques aux événements Landlock dans les logs collectés (ex. via go-libaudit) :

  • détection si domain et blockers existent dans l’événement.

Conclusion

Landlock est présenté comme :

  • un mécanisme de defense-in-depth efficace (réduit la surface d’attaque),
  • une télémétrie exploitable pour des détections comportementales précises,
  • un sujet à suivre car l’usage dans des outils open-source (et même l’intérêt des attaquants) suggère une adoption croissante côté Linux.

Conclusion: il s’agit d’une analyse technique visant à présenter l’intérêt de Landlock pour la sécurité et la télémétrie de détection.

🔗 Source originale : https://blog.sekoia.io/leveraging-landlock-telemetry-for-linux-detection-engineering/

🖴 Archive : https://web.archive.org/web/20260114090936/https://blog.sekoia.io/leveraging-landlock-telemetry-for-linux-detection-engineering/