Sécurité à l’exécution sous Linux

Le noyau Linux propose nativement une quantité impressionnante d’outils pour surveiller son exécution en temps réel : l’Audit Framework [1], Inotify [2], Fanotify [3], Perf, l’addition d’un nouveau module noyau, etc. Beaucoup de ces fonctionnalités du noyau ont été utilisées pour créer des outils de sécurité à l’exécution. Il est donc tout à fait normal de se sentir perdu lors de l'évaluation d’un outil de sécurité : le choix de la technologie sous-jacente a d’importantes conséquences sur la fiabilité et le contexte des alertes générées, et ces limites sont parfois difficiles à déceler. Dans cet article, nous allons parcourir les fonctionnalités du noyau permettant la création d'un tel outil, tout en évoquant leurs limites et en montrant pourquoi eBPF devient progressivement un acteur clé de la sécurité à l’exécution sous Linux.

1. Sécurité à l’exécution

1.1 De quoi s’agit-il et pourquoi est-ce important ?

La sécurité à l’exécution est la capacité à détecter des indicateurs de compromissions en temps réel, dans l’objectif d’alerter une équipe de réponse à incidents et de déployer des contre-mesures. Nous ne considérons ici que les indicateurs de compromissions à l’échelle d’une machine, et donc nous ne parlerons pas des solutions de type NIDS (Network Intrusion Detection Systems) qui fonctionnent en écoutant le trafic réseau à certains points clés de l’infrastructure.

Il existe de très nombreux indicateurs de compromission (IOC). Une façon de les classer consiste à les regrouper en fonction des ressources sur lesquelles ils reposent. Par exemple, certains IOC reposent sur des événements du système de fichiers : « un processus, qui n’est pas votre serveur web, a lu un fichier de configuration contenant les mots de passe de votre base de données » ; d’autres reposent sur des événements relatifs aux processus « un shell interactif a été démarré par un serveur web ». De même, on pourrait écrire des IOC sur des événements réseaux ou encore des événements relatifs au fonctionnement du noyau (comme le chargement d’un module noyau ou la modification de sa configuration).

La recherche en temps réel d’indicateurs de compromission est nécessaire pour améliorer la sécurité d’une infrastructure. Dans un premier temps, c’est un prérequis de plusieurs certifications de conformité. Par exemple, le standard Payment Card Industry (PCI) [4] requiert que soit déployé un outil surveillant les accès aux fichiers de configuration critiques d'une infrastructure. Ainsi, une entreprise voulant sauvegarder des données bancaires devra installer une solution de sécurité à l’exécution pour obtenir une attestation de conformité PCI [4].

Le principe de défense en profondeur est également une autre raison qui explique l’importance de la sécurité à l’exécution. Malgré toutes les mesures que pourrait prendre une équipe de sécurité pour protéger le développement d’applications, il est inévitable qu’une vulnérabilité finisse un jour en production. En effet, que ce soit à cause d’une dépendance de code tierce non mise à jour, ou simplement à cause d’une faille de sécurité introduite accidentellement par un développeur, la question est moins de savoir si la production sera atteinte, que de savoir comment limiter l’impact d’une vulnérabilité en production. C’est à ce moment-là que les différentes couches mises en place par les équipes de sécurité entrent en jeu, et se complètent pour protéger l’infrastructure et les données de l’entreprise.

En dehors même de la capacité de détection des vulnérabilités, il y a aussi le cas des services vulnérables connus qui ne peuvent pas être isolés au risque d’impacter trop profondément le service fourni par l’entreprise. Un exemple concret de ce phénomène se retrouve souvent dans l’utilisation à grande échelle de conteneurs dans une entreprise. En effet, une architecture fondée sur des microservices et déployée en conteneurs aura très probablement de nombreuses pipelines de construction et de test de ses conteneurs. Dans l’espoir d’unifier l’écosystème de l’infrastructure, et possiblement de déployer plus simplement des outils de monitoring, il est très probable que ces différentes pipelines construisent leurs conteneurs à partir de la même image de base (soit publique, soit contrôlée par l’entreprise). Lorsqu’une vulnérabilité est découverte dans cette image de base, c’est soudainement l’intégralité de l’infrastructure qui est à risque. On pourrait penser que ces pipelines permettent de déployer rapidement un patch de sécurité, et surtout partout dans l’infrastructure. Mais en réalité, l’expérience montre que les mainteneurs de ces pipelines seront très réticents à mettre à jour ces images de base, par peur de casser et de paralyser d’un seul coup l’intégralité des services en production. Dans ce genre de situation, un outil de sécurité à l’exécution permettrait de déployer rapidement un indicateur de compromission dans l'espoir de détecter et bloquer une attaque exploitant une vulnérabilité connue, donnant ainsi le temps aux différentes équipes de vérifier la fiabilité de la mise à jour des images de base.

1.2 Technologies existantes dans le noyau Linux

Même si la sécurité à l’exécution est en théorie une étape cruciale de la sécurisation d’une infrastructure, ce domaine de la sécurité est loin d’être un problème résolu. En étudiant les principales solutions de détection d’intrusions sur Linux, nous avons identifié quatre grandes catégories de limites. Il est important de noter que ces limites sont le plus souvent héritées des technologies utilisées en espace noyau pour émettre le flux d’événements analysé par la solution. C’est la raison pour laquelle nous allons nous concentrer sur les fonctionnalités du noyau utilisées pour implémenter une solution de sécurité à l’exécution, plutôt que sur les produits finis, dans l’espoir d’aider le lecteur à évaluer les inconvénients ou avantages d’une solution que l’on n’aurait pas listée.

Parmi toutes les solutions de sécurité à l’exécution que nous avons étudiées, voici les fonctionnalités de Linux les plus utilisées :

• L’Audit Framework de Linux [1] ;
• Inotify [2] ou Fanotify [3] ;
• Un flux d’événements Netlink, couplé avec le système de fichiers « proc » pour récupérer le contexte ;
• Un module noyau ou Linux Security Module (LSM) [10] ;
• Un flux d’événements Perf après enregistrement de différents points d’ancrage de type Kprobe [5] ou Tracepoint [12] ;
• Ptrace couplé avec des filtres seccomp-bpf ;
• LD_PRELOAD pour instrumenter la glibc ;
• Extended Berkeley Packet Filter (eBPF) [16].

Au lieu de parcourir ces technologies une par une, nous allons les ranger dans les quatre grandes catégories de limites que nous avons évoquées précédemment.

1.3 Les quatre grandes limites des solutions actuelles

1.3.1 Le contexte

Le premier et probablement plus important challenge de la majorité des technologies listées ci-dessus est le contexte apporté à l’événement généré. Par exemple, sans contexte sur le processus qui a déclenché une alerte, une équipe de réponse à incidents aura du mal à trier les alertes et à se concentrer sur les plus importantes. Le cas le plus flagrant de ce manque de contexte est l’ensemble des IOC sur le système de fichiers. Par exemple, une équipe de réponse à incidents ne voudra pas seulement savoir si un fichier de secrets a été ouvert, mais avant tout par quel processus et dans quel conteneur. Ces deux éléments de contexte permettent de filtrer les alertes et de savoir si un événement reporté par le noyau est légitime ou s’il est la preuve d’une intrusion. Sans contexte, l’équipe de sécurité finira par considérer les alertes comme étant du bruit et se verra contrainte de désactiver l’IOC. Ce sont les solutions fondées sur Inotify [2] qui sont ici majoritairement visées par cette limitation.

Le contexte du processus n’est pas le seul contexte manquant : les métadonnées sur le conteneur auquel le processus appartient sont aussi très souvent absentes. La raison qui explique ce manque de contexte est simplement le fait que les conteneurs sont un concept en espace utilisateur qui se traduit en namespaces et cgroups au sein de l’espace noyau. Si la technologie utilisée ne permet pas nativement de collecter les informations de namespace ou cgroup pour les événements générés, il sera quasiment impossible de garantir la fiabilité d’une association à un conteneur. En d’autres termes, les solutions de sécurité fondées sur l’Audit framework [1], Inotify [2], Fanotify [3], le flux d’événements Netlink, ptrace ou LD_PRELOAD vont toutes avoir de sérieux problèmes de contexte au niveau des conteneurs. Un contournement possible [6] de cette limitation repose sur une lecture asynchrone du système de fichiers « proc » pour récupérer le cgroup d’un processus, et enfin le résoudre en métadonnées de conteneurs avec l’aide de l’orchestrateur. Malheureusement, cette solution ne doit pas être considérée comme fiable puisqu’entre le moment où un événement est généré par le noyau, et le moment où la solution en espace utilisateur interroge le système de fichiers « proc », le processus pourrait avoir disparu. Pire, cela pourrait provoquer une perte de couverture avec faux négatifs si un IOC dépendait de la valeur d’une métadonnée de conteneur.

1.3.2 Le ratio entre signal à bruit et la perte de couverture

Ce problème est généralement une conséquence directe du premier point : moins il y a de contexte pour filtrer les alertes, plus il y a de faux positifs. Cette capacité de filtrage va également avoir un impact négatif sur la couverture puisqu’une équipe de sécurité constamment dérangée par une alerte inutilisable se verra dans l’obligation de l’ignorer, voire même de la désactiver.

Il y a aussi parfois des limites au niveau de la technologie elle-même, qui peuvent provoquer des pertes involontaires de couverture. Par exemple, lorsqu'une Kprobe [5] est utilisée pour générer des événements avec Perf, la profondeur de parcours des structures du noyau est limitée. Concrètement, dans un contexte d’analyse d’événements d’un système de fichiers, cela peut se traduire par une résolution partielle de chemins et donc d’une analyse sur des chemins tronqués. De même, analyser avec Ptrace les arguments de certains appels système capturés par un filtre seccomp-bpf est vulnérable à une attaque de type TOCTOU (Time-Of-Check Time-Of-Use) si plusieurs threads en space utilisateur partagent un pointeur vers les arguments des appels système.

1.3.3 Les performances

Une autre raison qui pousse souvent les équipes de sécurité à réduire leurs règles de détection est l'impact de ces règles en termes de performances sur la machine. Lors de l’évaluation des performances d’un outil de sécurité à l’exécution, il y a toujours deux parties à évaluer : l’impact de la technologie en espace noyau utilisée pour générer le flux d’événements, et l’impact de l’outil en espace utilisateur qui analyse les événements. D’après nos évaluations, le plus gros facteur influençant les performances est avant tout la quantité d’événements analysés en espace utilisateur (indépendamment de la technologie en espace noyau utilisée pour les générer). Autrement dit, plus la technologie en espace noyau permet de filtrer les événements tôt, moins l'impact sur la machine sera important. C’est la raison pour laquelle des technologies comme eBPF ou un module noyau sont particulièrement intéressantes.

1.3.4 La sûreté de fonctionnement

D’un point de vue de la sûreté de fonctionnement, les modules noyaux ont un problème majeur : ils demandent un très haut niveau de confiance en leur stabilité. Lorsqu’un module noyau plante, c'est l’intégralité de la machine qui doit redémarrer, menaçant ainsi la disponibilité des services en production. C’est une autre raison pour laquelle eBPF a à nouveau un avantage sur les autres approches. En effet, le but premier d’eBPF étant de garantir la stabilité et un faible impact sur les performances, le noyau limite le nombre d'instructions exécutées et applique des restrictions sur les accès mémoire au sein d’un programme eBPF.

2. eBPF, le nouveau couteau suisse de la sécurité à l’exécution sous Linux

eBPF semble donc être une technologie prometteuse pour implémenter un outil de sécurité à l’exécution. Dans cette partie, nous allons expliquer ce qu’est eBPF et comment cette technologie peut être utilisée pour répondre aux limites évoquées précédemment. Néanmoins, eBPF est une technologie complexe qui présente de nombreux pièges à éviter au risque de réduire de façon importante la couverture de sécurité.

2.1 Introduction rapide à eBPF

Extended Berkeley Packet Filter (eBPF) est un sous-système du noyau Linux qui permet d’exécuter du code dans une sandbox [8] en espace noyau. Les programmes eBPF sont chargés à l’exécution avec l’appel système « bpf », et subissent de nombreuses vérifications en espace noyau dans l’objectif de garantir :

• que les programmes se terminent ;
• qu’ils ne peuvent pas provoquer une faute de segmentation ;
• que leur stack est limitée à 512 octets.

D’autres règles sont également vérifiées (un programme a une taille maximum de 4k ou 1 million d’instructions en fonction de la version du noyau [7]), mais les plus importantes pour garantir la sûreté de fonctionnement d’eBPF sont les 3 règles listées ci-dessus.

Une fois un programme eBPF chargé, il faut indiquer au noyau comment l’exécuter. En d’autres termes, il faut définir le point d’ancrage qui doit déclencher l’exécution du programme. Il existe de nombreux types de programmes eBPF, et chaque type de programme a sa spécificité : le filtrage réseau, le traçage d’activités noyau, le traçage de programmes en space utilisateur, etc. Nous vous recommandons le livre « Linux Observability with BPF » [14] de David Calavera et Lorenzo Fontana pour une introduction à eBPF plus approfondie.

2.2 Une mine d’or pour la sécurité à l’exécution

Un des gros avantages de eBPF est que cette technologie permet de générer un flux d’événements pour presque n’importe quel type d’événements du noyau. En effet, il est possible d’attacher un programme eBPF sur n’importe quel symbole exporté du noyau en y plaçant un programme de type Kprobe [5]. Que ce soit dans le domaine des systèmes de fichiers, des processus ou du trafic réseau, eBPF pourra collecter tous les événements nécessaires à l’implémentation d’un outil de sécurité à l’exécution. Il est également possible de s’attacher à certaines fonctions critiques du noyau pour détecter des comportements anormaux, pouvant venir d’un malware. Par exemple, il sera possible de détecter qu’un processus en espace utilisateur essaye d’insérer un nouveau module noyau, ou de désactiver SELinux. En d’autres termes, les capacités d’introspection proposées par eBPF s'approchent de ce qu’il serait possible de faire avec un module noyau, sans l’inconvénient des problèmes de sûreté.

Un bel exemple de cette grande souplesse est la possibilité de récupérer, pour n’importe quel type d’événement, le cgroup du processus en espace utilisateur qui a provoqué l’exécution d’un programme eBPF. Concrètement, cela signifie qu’il est possible d’associer avec certitude le processus et le conteneur ID du processus qui a provoqué une alerte. Ensuite, il ne reste plus qu’à interroger l’orchestrateur de conteneurs en espace utilisateur pour collecter les métadonnées du conteneur. C’est ainsi qu’eBPF peut supporter « nativement » l’association des alertes à un conteneur, sans risquer des problèmes de synchronisation avec le système de fichiers « proc », problèmes dont souffrent la plupart des technologies de surveillance en espace noyau.

eBPF présente également un mécanisme intéressant dans un contexte de sécurité dynamique : les « eBPF maps ». En effet, ces maps sont un moyen de sauvegarder ou de récupérer des données pendant l’exécution d’un programme eBPF. Elles peuvent également être lues et modifiées par un programme en espace utilisateur, et donc permettent d’extraire des données d’une activité en espace noyau, ou au contraire de pousser des filtres en espace noyau à l’exécution. Cela permet de changer dynamiquement l'impact de la solution de sécurité sur les performances de la machine en augmentant ou diminuant le nombre d’événements envoyés en espace utilisateur.

eBPF profite d’un engouement croissant et évolue rapidement au sein du noyau Linux. Par exemple, Kernel Runtime Security Instrumentation (KRSI) [9] a récemment été ajouté dans le noyau. KRSI introduit la possibilité d’utiliser des programmes eBPF pour implémenter un Linux Security Module [10]. En d’autres termes, cela signifie qu’à partir de la version 5.6 du noyau, il est possible de bloquer des opérations en espace noyau en fonction de l’évaluation d’un programme eBPF. Combiné avec tout ce qui a été dit précédemment, cette avancée majeure d’eBPF dans le noyau garantit que cette technologie n’a pas encore fini de faire parler d’elle dans le domaine de la sécurité à l’exécution.

2.3 Retour d’expérience

Même si eBPF semble être une solution très attrayante pour un outil de sécurité à l’exécution, cette technologie présente en réalité de nombreux pièges dans lesquels il ne faut pas tomber, au risque de réduire de façon importante la couverture de sécurité. En effet, un certain nombre de règles ne sont pas explicitées ou sont peu documentées. Il faut probablement les enfreindre au moins une fois pour être sûr de ne plus jamais les oublier ! Nous ne parlerons ici que des quatre plus importants inconvénients que nous avons rencontrés lors de l’implémentation de notre outil de sécurité dans l’agent de Datadog [13][15] :

• La première difficulté est liée à l’utilisation de points d’ancrage de type Kprobe [5]. En effet, ces points d’ancrage permettent d’attacher un programme eBPF à un symbole du noyau. Or le noyau est en constante évolution, et même si certains sous-systèmes du noyau sont relativement stables, il arrive que des fonctions disparaissent ou soient renommées. Si vous avez besoin de mettre un programme eBPF sur l’un de ces symboles, il faudra donc s’assurer qu’il existe sur toutes les versions du noyau et des distributions que vous souhaitez supporter. Si vous décidez de vous mettre au niveau des appels système, il faudra également vérifier que de nouveaux appels système ne permettent pas d’exécuter indirectement l’opération que vous souhaitiez surveiller (les syscalls « io_uring » [11] sont un bon exemple de ce problème). En résumé, la stabilité des points d’ancrage avec eBPF n’est pas garantie, et il faut donc constamment vérifier la compatibilité des programmes que vous écrivez.
• Une seconde limitation d’eBPF qu’il ne faut pas minimiser est le paramètre « maxactive » des points d’ancrage de type Kretprobe. Ces points d’ancrage permettent de déclencher un programme eBPF au retour d’une fonction, au lieu de son entrée. Le paramètre « maxactive » détermine combien d’appels de fonction concurrents peuvent déclencher un programme Kretprobe. Si ce paramètre est trop petit et qu’une fonction est appelée plusieurs fois (suite à une préemption ou simplement à cause d’une concurrence entre plusieurs cores de processeur), vous pourrez potentiellement perdre des appels de fonction, et donc introduire une importante perte de couverture.
• Les paramètres des syscalls ne sont pas toujours lisibles depuis eBPF à l’entrée d’un syscall. L’explication technique est simplement qu’eBPF n’a pas le droit de résoudre les fautes de page. Il faut donc privilégier la lecture d’arguments venant d’espace utilisateur depuis un programme Kretprobe au lieu de Kprobe [5].
• Enfin, les points d’ancrage de type Tracepoint [12] sur appels systèmes ne sont pas déclenchés par la convention d’appel « ia32 ». En d’autres termes, un programme 32 bits sur une machine 64 bits ne déclenchera pas vos programmes eBPF de type Tracepoint [12] attachés à des syscalls.

Conclusion

La sécurité à l’exécution sur Linux est un sujet passionnant et en constante évolution. eBPF est une technologie très prometteuse pour le développement de solutions de sécurité, mais de nombreuses pistes restent encore à explorer. Gageons que son utilisation ne fera qu’augmenter dans les prochaines années grâce à son évolution rapide dans le noyau Linux.

Références

[1] Linux Audit Documentation : https://github.com/linux-audit/audit-documentation/wiki

[2] Filesystem notification, lwn.net : https://lwn.net/Articles/604686

[3] Fanotify man page : https://man7.org/linux/man-pages/man7/fanotify.7.html

[4] Payment Card Industry security standards : https://www.pcisecuritystandards.org/documents/Prioritized-Approach-for-PCI_DSS-v3_2.pdf

[5] Kprobe documentation : https://www.kernel.org/doc/Documentation/kprobes.txt

[6] Solution de contournement de go-audit pour récupérer le container ID d’un processus : https://github.com/slackhq/go-audit/blob/d3dd09bab49077bb4f6998609acbed71fb659fdd/extras_containers_capsule8.go

[7] Improve verifier scalability, lwn.net : https://lwn.net/Articles/784571

[8] BPF: the universal in-kernel virtual machine, lwn.net : https://lwn.net/Articles/599755

[9] Kernel Runtime Security Instrumentation, lwn.net : https://lwn.net/Articles/798918

[10] Writing your own security module, lwn.net : https://lwn.net/Articles/674949

[11] Appel système io_uring_enter : https://manpages.debian.org/unstable/liburing-dev/io_uring_enter.2.en.html

[12] Tracepoints, Kernel documentation : https://www.kernel.org/doc/html/latest/trace/tracepoints.html

[13] Datadog Agent, dépôt de code : https://github.com/DataDog/datadog-agent

[14] Lorenzo Fontana, David Calavera. « Linux Observability with BPF », O'Reilly Media, novembre 2019

[15] Secure your infrastructure in real time with Datadog Runtime Security : https://www.datadoghq.com/blog/datadog-runtime-security

[16] A thorough introduction to eBPF, lwn.net : https://lwn.net/Articles/740157