Livre « BPF pour la surveillance de Linux »

Bonjour, membres de Habr! La machine virtuelle BPF est l'un des composants les plus importants du noyau Linux. Son utilisation appropriée permettra aux ingénieurs systèmes de détecter des pannes et de résoudre même les problèmes les plus complexes. Vous apprendrez à créer des programmes qui suivent et modifient le comportement du noyau, à intégrer du code pour surveiller en toute sécurité les événements du noyau et bien plus encore. David Calavera et Lorenzo Fontana vous aideront à exploiter les capacités de BPF. Élargissez vos connaissances sur l'optimisation des performances, les réseaux, la sécurité. — Utilisez BPF pour suivre et modifier le comportement du noyau Linux. — Intégrez du code pour surveiller en toute sécurité les événements du noyau, sans avoir besoin de recompiler le noyau ou de redémarrer le système. — Profitez d'exemples de code pratiques en C, Go ou Python. — Prenez le contrôle en maîtrisant le cycle de vie du programme BPF.

Sécurité du noyau Linux, ses capacités et Seccomp

BPF offre un moyen puissant d'étendre le noyau sans compromettre la stabilité, la sécurité et la vitesse. Pour cette raison, les développeurs du noyau ont pensé qu'il serait intéressant d'utiliser sa polyvalence pour améliorer l'isolation des processus dans Seccomp en mettant en œuvre des filtres Seccomp soutenus par des programmes BPF, connus sous le nom de Seccomp BPF. Dans ce chapitre, nous expliquerons ce qu'est Seccomp et comment il est appliqué. Ensuite, vous apprendrez à écrire des filtres Seccomp à l'aide de programmes BPF. Nous examinerons ensuite les pièges BPF intégrés qui existent dans le noyau pour les modules de sécurité Linux.

Les modules de sécurité Linux (LSM) sont une plateforme offrant un ensemble de fonctionnalités qui peuvent être utilisées pour la mise en œuvre standardisée de divers modèles de sécurité. LSM peut être utilisé directement dans l'arborescence du code source du noyau, comme Apparmor, SELinux et Tomoyo.

Commençons par discuter des capacités de Linux.

Fonctionnalités

L'essence des capacités de Linux repose sur le fait que vous devez donner à un processus non privilégié l'autorisation d'exécuter une tâche spécifique, mais sans utiliser suid à cette fin, ou autrement devenir un processus privilégié, réduisant ainsi les possibilités d'attaque et permettant au processus d'exécuter certaines tâches. Par exemple, si votre application doit ouvrir un port privilégié, disons le 80, au lieu de lancer le processus en tant que root, vous pouvez simplement lui accorder la possibilité CAP_NET_BIND_SERVICE.

Considérons un programme Go nommé main.go :

package main
import (
            "net/http"
            "log"
)
func main() {
     log.Fatalf("%v", http.ListenAndServe(":80", nil))
}

Ce programme sert un serveur HTTP sur le port 80 (c'est un port privilégié). Normalement, nous l'exécutons immédiatement après la compilation :

$ go build -o capabilities main.go
$ ./capabilities

Cependant, comme nous ne fournissons pas de privilèges root, ce code renverra une erreur lors de la liaison au port :

2019/04/25 23:17:06 listen tcp :80: bind: permission denied
exit status 1

capsh (outil de gestion de shell) est un outil qui lance un shell avec un certain ensemble de capacités.

Dans ce cas, comme mentionné, au lieu de fournir des droits root complets, nous pouvons permettre la liaison des ports privilégiés en accordant la capacité cap_net_bind_service ainsi que toutes les autres déjà présentes dans le programme. Pour cela, nous pouvons envelopper notre programme dans capsh :

# capsh --caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' 
   --keep=1 --user="nobody" 
   --addamb=cap_net_bind_service -- -c "./capabilities"

Décomposons un peu cette commande.

• capsh — nous utilisons capsh comme shell.
• —caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' — puisque nous devons changer d'utilisateur (nous ne voulons pas être exécutés avec les droits root), nous indiquerons cap_net_bind_service et la capacité de changer effectivement l'identifiant utilisateur de root à nobody, à savoir cap_setuid et cap_setgid.
• —keep=1 — nous voulons conserver les capacités établies lors de la transition depuis le compte root.
• —user="nobody" — l'utilisateur final qui exécutera le programme sera nobody.
• —addamb=cap_net_bind_service — nous définissons le nettoyage des capacités associées après le passage en mode root.
• — -c "./capabilities" — nous exécutons simplement le programme.

Les capacités associées sont un type spécial de capacités héritées par les programmes enfants lorsque le programme actuel les exécute via execve(). Seules les capacités autorisées comme associées, ou, en d'autres termes, comme capacités d'environnement, peuvent être héritées.

Vous vous demandez probablement ce que signifie +eip après avoir indiqué une capacité dans l'option —caps. Ces drapeaux sont utilisés pour déterminer que la capacité :

- doit être activée (p) ;

- est disponible pour l'application (e) ;

- peut être héritée par les processus enfants (i).

Comme nous voulons utiliser cap_net_bind_service, nous devons le faire avec le drapeau e. Ensuite, nous lancerons un shell dans la commande. Cela exécutera le fichier binaire capabilities, et nous devons le marquer avec le drapeau i. Enfin, nous voulons que la capacité soit activée (nous l'avons fait sans changer l'UID) avec p. Cela ressemble à cap_net_bind_service+eip.

Vous pouvez vérifier le résultat avec ss. Nous allons réduire légèrement la sortie pour qu'elle tienne sur la page, mais elle montrera le port associé et l'identifiant utilisateur différent de 0, dans ce cas précis 65 534 :

# ss -tulpn -e -H | cut -d' ' -f17-
128 *:80 *:*
users:(("capabilities",pid=30040,fd=3)) uid:65534 ino:11311579 sk:2c v6only:0

Dans cet exemple, nous avons utilisé capsh, mais vous pouvez écrire un shell avec libcap. Pour plus d'informations, consultez man 3 libcap.

Lors de l'écriture de programmes, le développeur ne connaît souvent pas à l'avance toutes les capacités nécessaires au programme pendant l'exécution ; de plus, dans les nouvelles versions, ces capacités peuvent changer.

Pour mieux comprendre les capacités de notre programme, nous pouvons prendre l'outil BCC capable, qui installe un kprobe pour la fonction noyau cap_capable :

/usr/share/bcc/tools/capable
TIME      UID  PID   TID   COMM               CAP    NAME           AUDIT
10:12:53 0 424     424     systemd-udevd 12 CAP_NET_ADMIN         1
10:12:57 0 1103   1101   timesync        25 CAP_SYS_TIME         1
10:12:57 0 19545 19545 capabilities       10 CAP_NET_BIND_SERVICE 1

Nous pouvons obtenir le même résultat en utilisant bpftrace avec un kprobe en une ligne dans la fonction noyau cap_capable :

bpftrace -e 
   'kprobe:cap_capable {
      time("%H:%M:%S ");
      printf("%-6d %-6d %-16s %-4d %dn", uid, pid, comm, arg2, arg3);
    }' 
    | grep -i capabilities

Cela affichera quelque chose comme ce qui suit, si les capacités de notre programme sont activées après le kprobe :

12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 10 1

La cinquième colonne contient les capacités dont le processus a besoin, et comme ces résultats incluent également des événements non audités, nous voyons toutes les vérifications non auditées et enfin la capacité requise avec le drapeau d'audit (le dernier dans la sortie) défini sur 1. La capacité qui nous intéresse est CAP_NET_BIND_SERVICE, elle est définie comme une constante dans le code source du noyau dans le fichier include/uapi/linux/ability.h avec l'identifiant 10 :

/* Allows binding to TCP/UDP sockets below 1024 */
/* Allows binding to ATM VCIs below 32 */
#define CAP_NET_BIND_SERVICE 10<source lang="go">

Les capacités sont souvent utilisées lors de l'exécution de conteneurs, tels que runC ou Docker, pour qu'ils fonctionnent en mode non privilégié, mais on ne leur accorde que les capacités nécessaires au fonctionnement de la plupart des applications. Lorsque l'application nécessite des capacités spécifiques, celles-ci peuvent être accordées dans Docker avec —cap-add :

docker run -it --rm --cap-add=NET_ADMIN ubuntu ip link add dummy0 type dummy

Cette commande donnera au conteneur la capacité CAP_NET_ADMIN, ce qui lui permettra de configurer le lien réseau pour ajouter l'interface dummy0.

La section suivante montre l'utilisation de capacités telles que le filtrage, mais avec une méthode différente qui nous permettra d'implémenter nos propres filtres par programmation.

Seccomp

Seccomp signifie Secure Computing, c'est un niveau de sécurité mis en œuvre dans le noyau Linux qui permet aux développeurs de filtrer certains appels système. Bien que Seccomp soit comparable aux capacités Linux, sa capacité à gérer certains appels système le rend beaucoup plus flexible par rapport à eux.

Seccomp et les capacités Linux ne s'excluent pas mutuellement, ils sont souvent utilisés ensemble pour bénéficier des deux approches. Par exemple, vous pouvez souhaiter accorder au processus la capacité CAP_NET_ADMIN, mais ne pas lui permettre d'accepter des connexions via un socket, en bloquant les appels système accept et accept4.

La méthode de filtrage Seccomp repose sur des filtres BPF opérant en mode SECCOMP_MODE_FILTER, et le filtrage des appels système est effectué de la même manière que pour les paquets.

Les filtres Seccomp sont chargés à l'aide de prctl via l'opération PR_SET_SECCOMP. Ces filtres prennent la forme d'un programme BPF qui est exécuté pour chaque paquet Seccomp présenté à l'aide de la structure seccomp_data. Cette structure contient l'architecture de référence, le pointeur d'instruction du processeur lors de l'appel système et jusqu'à six arguments d'appel système, exprimés sous forme de uint64.

Voici à quoi ressemble la structure seccomp_data dans le code source du noyau dans le fichier linux/seccomp.h :

struct seccomp_data {
int nr;
      __u32 arch;
      __u64 instruction_pointer;
      __u64 args[6];
};

Comme on peut le voir dans cette structure, nous pouvons filtrer par appel système, ses arguments ou leur combinaison.

Après avoir reçu chaque paquet, le filtre Seccomp doit effectuer un traitement pour prendre une décision finale et informer le noyau de la suite à donner. La décision finale est exprimée par l'une des valeurs de retour (codes d'état).

— SECCOMP_RET_KILL_PROCESS — terminaison de l'ensemble du processus immédiatement après le filtrage de l'appel système, qui ne s'exécute donc pas.

— SECCOMP_RET_KILL_THREAD — terminaison du thread courant immédiatement après le filtrage de l'appel système, qui ne s'exécute donc pas.

— SECCOMP_RET_KILL — alias pour SECCOMP_RET_KILL_THREAD, laissé pour des raisons de compatibilité.

— SECCOMP_RET_TRAP — l'appel système est interdit et le signal SIGSYS (Bad System Call) est envoyé à la tâche qui l'a appelé.

— SECCOMP_RET_ERRNO — l'appel système n'est pas exécuté et une partie de la valeur retournée par le filtre SECCOMP_RET_DATA est transmise à l'espace utilisateur comme valeur errno. Différentes valeurs errno sont retournées selon la cause de l'erreur. Une liste des numéros d'erreur est fournie dans la section suivante.

— SECCOMP_RET_TRACE — utilisé pour notifier le traceur ptrace avec — PTRACE_O_TRACESECCOMP afin d'intercepter l'exécution de l'appel système pour voir et contrôler ce processus. Si le traceur n'est pas connecté, une erreur est retournée, errno est défini sur -ENOSYS, et l'appel système n'est pas exécuté.

— SECCOMP_RET_LOG — l'appel système est autorisé et enregistré dans le journal.

— SECCOMP_RET_ALLOW — l'appel système est simplement autorisé.

ptrace est un appel système permettant de mettre en œuvre des mécanismes de traçage dans un processus appelé tracee, avec la possibilité d'observer et de contrôler l'exécution du processus. Le programme de traçage peut influencer efficacement l'exécution et modifier les registres mémoire de tracee. Dans le contexte de Seccomp, ptrace est utilisé lorsque le code d'état SECCOMP_RET_TRACE est déclenché, permettant ainsi au traceur d'empêcher l'exécution de l'appel système et de mettre en œuvre sa propre logique.

Erreurs Seccomp

De temps à autre, en travaillant avec Seccomp, vous rencontrerez différentes erreurs qui sont identifiées par la valeur de retour de type SECCOMP_RET_ERRNO. Pour signaler une erreur, l'appel système seccomp retournera -1 au lieu de 0.

Les erreurs suivantes sont possibles :

— EACCESS — l'appelant n'est pas autorisé à effectuer un appel système. Cela se produit généralement parce qu'il n'a pas les privilèges CAP_SYS_ADMIN ou que no_new_privs n'est pas défini via prctl (nous en parlerons plus tard);

— EFAULT — les arguments transférés (args dans la structure seccomp_data) n'ont pas d'adresse valide;

— EINVAL — il peut y avoir quatre raisons ici :

- l'opération demandée est inconnue ou non prise en charge par le noyau dans la configuration actuelle;

- les drapeaux spécifiés sont invalides pour l'opération demandée;

- l'opération implique BPF_ABS, mais il y a des problèmes avec le décalage spécifié, qui peut dépasser la taille de la structure seccomp_data;

- le nombre d'instructions transmises au filtre dépasse le maximum;

— ENOMEM — mémoire insuffisante pour exécuter le programme;

— EOPNOTSUPP — l'opération a indiqué que l'action SECCOMP_GET_ACTION_AVAIL était disponible, cependant le noyau ne prend pas en charge le retour dans les arguments;

— ESRCH — un problème est survenu lors de la synchronisation d'un autre thread;

— ENOSYS — il n'y a pas de traceur attaché à l'action SECCOMP_RET_TRACE.

prctl est un appel système qui permet à un programme en espace utilisateur de gérer (définir et obtenir) des aspects spécifiques du processus, tels que le numéro de série des octets, les noms de threads, le mode de calcul sécurisé (Seccomp), les privilèges, les événements Perf, etc.

Le Seccomp peut sembler être une technologie de bac à sable, mais ce n'est pas le cas. Seccomp est un utilitaire qui permet aux utilisateurs de développer un mécanisme de bac à sable. Voyons maintenant comment créer des programmes d'interaction utilisateur à l'aide d'un filtre appelé directement par l'appel système Seccomp.

Exemple de filtre BPF Seccomp

Ici, nous allons montrer comment combiner les deux actions précédemment examinées, à savoir :

— écrire un programme Seccomp BPF qui sera utilisé comme filtre avec différents codes de retour en fonction des décisions prises;

— charger le filtre en utilisant prctl.

Tout d'abord, il faut des en-têtes de la bibliothèque standard et du noyau Linux :

#include <errno.h>
#include <linux/audit.h>
#include <linux/bpf.h>
#include <linux/filter.h>
#include <linux/seccomp.h>
#include <linux/unistd.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <unistd.h>

Avant d'essayer d'exécuter cet exemple, nous devons nous assurer que le noyau a été compilé avec CONFIG_SECCOMP et CONFIG_SECCOMP_FILTER définis sur y. Sur une machine de travail, cela peut être vérifié comme suit :

cat /proc/config.gz | zcat | grep -i CONFIG_SECCOMP

Le reste du code est une fonction install_filter, composée de deux parties. La première partie contient notre liste d'instructions de filtrage BPF :

static int install_filter(int nr, int arch, int error) {
  struct sock_filter filter[] = {
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, arch))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3),
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, nr))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW),
  };

Les instructions sont définies à l'aide des macro-commandes BPF_STMT et BPF_JUMP, définies dans le fichier linux/filter.h.
Passons en revue les instructions.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, arch))) — le système charge et empile avec BPF_LD sous la forme d'un mot BPF_W, les données du paquet sont situées à un décalage fixe BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) — vérifie à l'aide de BPF_JEQ si la valeur de l'architecture dans le registre constant BPF_K est égale à arch. Si c'est le cas, il passe avec un décalage de 0 à l'instruction suivante, sinon, pour générer une erreur, il sautera avec un décalage de 3 (dans ce cas), parce que arch ne correspond pas.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr))) — charge et empile avec BPF_LD sous la forme d'un mot BPF_W, qui est le numéro de l'appel système situé à un décalage fixe BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1) — compare le numéro de l'appel système à la valeur de la variable nr. S'ils sont égaux, il passe à l'instruction suivante et interdit l'appel système, sinon il autorise l'appel système avec SECCOMP_RET_ALLOW.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)) — termine le programme avec BPF_RET et génère une erreur SECCOMP_RET_ERRNO avec le numéro de la variable err.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW) — termine le programme avec BPF_RET et autorise l'exécution de l'appel système avec SECCOMP_RET_ALLOW.

SECCOMP EST UN CBPF
Peut-être vous demandez-vous pourquoi une liste d'instructions est utilisée plutôt qu'un objet ELF compilé ou un programme en C compilé avec JIT.

Il y a deux raisons à cela.

• Tout d'abord, Seccomp utilise cBPF (classical BPF) et non eBPF, ce qui signifie : il n'a pas de registres, mais seulement un accumulateur pour stocker le dernier résultat des calculs, comme on peut le voir dans l'exemple.

• Deuxièmement, Seccomp prend un pointeur vers un tableau d'instructions BPF directement et rien de plus. Les macros que nous avons utilisées aident simplement à spécifier ces instructions dans un format compréhensible pour les développeurs.

Si vous avez besoin d'aide supplémentaire pour comprendre cette construction, envisagez le pseudocode qui fait la même chose :

if (arch != AUDIT_ARCH_X86_64) {
    return SECCOMP_RET_ALLOW;
}
if (nr == __NR_write) {
    return SECCOMP_RET_ERRNO;
}
return SECCOMP_RET_ALLOW;

Après avoir défini le code de filtre dans la structure socket_filter, vous devez définir sock_fprog, qui contient le code et la longueur calculée du filtre. Cette structure de données est nécessaire comme argument pour déclarer le fonctionnement du processus par la suite :

struct sock_fprog prog = {
   .len = (unsigned short)(sizeof(filter) / sizeof(filter[0])),
   .filter = filter,
};

Il ne reste plus qu'une chose à faire dans la fonction install_filter : charger le programme lui-même ! Pour cela, nous utilisons prctl, avec PR_SET_SECCOMP comme option, pour entrer en mode de calcul sécurisé. Ensuite, nous spécifions au mode de charger le filtre avec SECCOMP_MODE_FILTER, qui est contenu dans la variable prog de type sock_fprog :

  if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog)) {
    perror("prctl(PR_SET_SECCOMP)");
    return 1;
  }
  return 0;
}

Enfin, nous pouvons utiliser notre fonction install_filter, mais avant cela, nous devons utiliser prctl pour définir PR_SET_NO_NEW_PRIVS pour l'exécution actuelle, évitant ainsi que les processus fils obtiennent des privilèges plus larges que ceux des parents. Cela nous permet d'effectuer les appels prctl suivants dans la fonction install_filter sans avoir les droits root.

Nous pouvons maintenant appeler la fonction install_filter. Bloquons tous les appels système write liés à l'architecture X86-64 et donnons simplement la permission, bloquant ainsi toutes les tentatives. Après la mise en place du filtre, continuons l'exécution en utilisant le premier argument :

int main(int argc, char const *argv[]) {
  if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
   perror("prctl(NO_NEW_PRIVS)");
   return 1;
  }
   install_filter(__NR_write, AUDIT_ARCH_X86_64, EPERM);
  return system(argv[1]);
 }

Commençons. Pour compiler notre programme, nous pouvons utiliser soit clang, soit gcc, dans tous les cas, il s'agit simplement de la compilation du fichier main.c sans options spéciales :

clang main.c -o filter-write

Comme déjà mentionné, nous avons bloqué toutes les écritures dans le programme. Pour vérifier cela, nous avons besoin d'un programme qui produit quelque chose, et ls semble être un bon candidat. Voici comment il se comporte généralement :

ls -la
total 36
drwxr-xr-x 2 fntlnz users 4096 Apr 28 21:09 .
drwxr-xr-x 4 fntlnz users 4096 Apr 26 13:01 ..
-rwxr-xr-x 1 fntlnz users 16800 Apr 28 21:09 filter-write
-rw-r--r-- 1 fntlnz users 19 Apr 28 21:09 .gitignore
-rw-r--r-- 1 fntlnz users 1282 Apr 28 21:08 main.c

C'est formidable ! Voici comment utiliser notre programme shell : il suffit de transmettre le programme que nous voulons tester en tant que premier argument :

./filter-write "ls -la"

Après exécution, ce programme produit une sortie complètement vide. Cependant, nous pouvons appliquer strace pour voir ce qui se passe :

strace -f ./filter-write "ls -la"

Le résultat est considérablement abrégé, mais la partie pertinente montre que les enregistrements sont bloqués avec l'erreur EPERM — celle que nous avons configurée. Cela signifie que le programme ne produit aucune sortie, car il ne peut pas accéder à l'appel système write :

[pid 25099] write(2, "ls: ", 4) = -1 EPERM (Operation not permitted)
[pid 25099] write(2, "write error", 11) = -1 EPERM (Operation not permitted)
[pid 25099] write(2, "n", 1) = -1 EPERM (Operation not permitted)

Vous comprenez maintenant comment fonctionne Seccomp BPF et vous avez une bonne idée de ce que l'on peut en faire. Mais ne voudrais-vous pas obtenir le même résultat avec eBPF au lieu de cBPF, pour exploiter toute sa puissance ?

En réfléchissant aux programmes eBPF, la plupart des gens pensent qu'ils se contentent de les écrire et de les charger avec des privilèges d'administrateur. Bien que cette affirmation soit globalement vraie, le noyau met en œuvre un ensemble de mécanismes pour protéger les objets eBPF à différents niveaux. Ces mécanismes sont appelés points de piégeage BPF LSM.

Points de piégeage BPF LSM

Pour garantir un contrôle des événements systèmes indépendant de l'architecture, LSM met en œuvre le concept de points de piégeage. Techniquement, l'appel d'un point de piégeage ressemble à un appel système, mais est indépendant du système et intégré à l'infrastructure. LSM fournit un nouveau concept, dans lequel le niveau d'abstraction peut aider à éviter les problèmes rencontrés lors de l'utilisation d'appels systèmes sur différentes architectures.

Au moment de la rédaction de ce livre, le noyau avait sept points de piégeage associés aux programmes BPF, et SELinux était le seul LSM intégré qui les réalisait.

Le code source des points de piégeage est localisé dans l'arborescence du noyau dans le fichier include/linux/security.h :

extern int security_bpf(int cmd, union bpf_attr *attr, unsigned int size);
extern int security_bpf_map(struct bpf_map *map, fmode_t fmode);
extern int security_bpf_prog(struct bpf_prog *prog);
extern int security_bpf_map_alloc(struct bpf_map *map);
extern void security_bpf_map_free(struct bpf_map *map);
extern int security_bpf_prog_alloc(struct bpf_prog_aux *aux);
extern void security_bpf_prog_free(struct bpf_prog_aux *aux);

Chacune d'entre elles sera appelée à différents moments de l'exécution :

— security_bpf — effectue une première vérification des appels système BPF exécutés ;

— security_bpf_map — vérifie quand le noyau retourne un descripteur de fichier pour une carte ;

— security_bpf_prog — vérifie quand le noyau retourne un descripteur de fichier pour un programme eBPF ;

— security_bpf_map_alloc — vérifie si le champ de sécurité à l'intérieur des cartes BPF est initialisé ;

— security_bpf_map_free — vérifie si le nettoyage du champ de sécurité à l'intérieur des cartes BPF est effectué ;

— security_bpf_prog_alloc — vérifie si le champ de sécurité à l'intérieur des programmes BPF est initialisé ;

— security_bpf_prog_free — vérifie si le champ de sécurité à l'intérieur des programmes BPF est nettoyé.

Maintenant, en voyant tout cela, nous comprenons : l'idée des interceptors LSM BPF est qu'ils peuvent protéger chaque objet eBPF, en garantissant que seuls ceux qui ont les privilèges appropriés peuvent effectuer des opérations sur les cartes et les programmes.

Résumé

La sécurité n'est pas quelque chose que vous pouvez implanter de manière universelle pour tout ce que vous souhaitez protéger. Il est important de pouvoir protéger les systèmes à différents niveaux et de différentes manières. Que vous le croyiez ou non, la meilleure façon de sécuriser un système est d'organiser différents niveaux de protection à partir de différentes positions, de sorte que la réduction de la sécurité d'un niveau n'entraîne pas l'accès à l'ensemble du système. Les développeurs du noyau ont fait un grand travail en nous fournissant un ensemble de différentes couches et points d'interaction. Nous espérons vous avoir donné une bonne idée de ce que sont les couches et comment utiliser les programmes BPF pour travailler avec elles.

À propos des auteurs

David Calavera est directeur technique chez Netlify. Il a travaillé au support de Docker et a participé au développement d'outils comme Runc, Go et BCC, ainsi que d'autres projets open source. Il est connu pour son travail sur les projets Docker et le développement de l'écosystème des plugins Docker. David est passionné par les graphiques de flammes et cherche toujours à optimiser les performances.

Lorenzo Fontana Il travaille au sein de l'équipe de développeurs de logiciels open source chez Sysdig, où il se concentre principalement sur Falco — un projet de la Cloud Native Computing Foundation qui assure la sécurité des environnements d'exécution des conteneurs et la détection d'anomalies via un module de noyau et eBPF. Il est passionné par les systèmes distribués, les réseaux définis par logiciel, le noyau Linux et l'analyse des performances.

» Pour plus de détails sur le livre, vous pouvez consulter le site de l'éditeur
» Table des matières
» Extrait

Pour les membres de Habr, une remise de 25 % avec le code promotionnel — Linux

Après le paiement de la version papier du livre, un livre électronique sera envoyé par e-mail.

Source : habr.com