Si seccomp groupait les syscalls tu pourrais utiliser des « policies » identiques.
C'est exactement ce qui a été proposé dans les commentaires de l'article sur LWN.net. Il y a eu proposition pour développer une bibliothèque équivalente au syscall tame(2) avec les mêmes fonctions/fonctionnalités/interface se basant sur seccomp pour gérer les syscalls. Je trouve que c'est une super idée.
il faut quand même déterminer ce qu'on veut autoriser le programme à faire ou non.
Alors en fait pas vraiment, si tu sais que ton programme a besoin d'accéder au système de fichiers, tu demandes à tame(2) d'autoriser l'utilisation des syscall travaillant sur le système de fichiers (avec distinction READONLY, WRITEONLY, RW). Si tu as besoin du réseau, tu demandes à tame(2) d'autoriser les syscalls pour l'accès réseau, etc.
Pour la distinction entre l'initialisation et la boucle principale c'est un peu plus compliqué mais on pourrait imaginer une « policy » seccomp ou autre qui n'est activée qu'après un fork() par exemple.
Côté Linux, ça pourrait être fait, mais côté OpenBSD je ne pense pas qu'il y ait grand chose de fait à la base (seccomp n'existe pas dans OpenBSD). Le principe, c'est de dire :
je lance un programme
ce programme effectue toutes ses opérations privilégiées à ce moment, et ne les fera plus
il appelle tame(2) pour réduire ses capacités au strict nécessaire pour son fonctionnement nominal
si un appel à un syscall non autorisé est effectué, c'est que l'on n'est pas dans un comportement nominal (tentative d'exécution frauduleuse d'une opération non prévue ? Buffer overflow ?)
Je pense que pour Theo, ça n'augmente pas réellement la charge de travail/maintenance de leurs outils, car via tame(2) ils n'ont pas d'audit de code à conduire pour déterminer la liste EXACTE des syscalls autorisés.
[^] # Re: seccomp-bpf
Posté par ntimeu . En réponse au journal Tame et OpenBSD. Évalué à 2.
C'est exactement ce qui a été proposé dans les commentaires de l'article sur LWN.net. Il y a eu proposition pour développer une bibliothèque équivalente au syscall tame(2) avec les mêmes fonctions/fonctionnalités/interface se basant sur seccomp pour gérer les syscalls. Je trouve que c'est une super idée.
Alors en fait pas vraiment, si tu sais que ton programme a besoin d'accéder au système de fichiers, tu demandes à tame(2) d'autoriser l'utilisation des syscall travaillant sur le système de fichiers (avec distinction READONLY, WRITEONLY, RW). Si tu as besoin du réseau, tu demandes à tame(2) d'autoriser les syscalls pour l'accès réseau, etc.
Côté Linux, ça pourrait être fait, mais côté OpenBSD je ne pense pas qu'il y ait grand chose de fait à la base (seccomp n'existe pas dans OpenBSD). Le principe, c'est de dire :
Je pense que pour Theo, ça n'augmente pas réellement la charge de travail/maintenance de leurs outils, car via tame(2) ils n'ont pas d'audit de code à conduire pour déterminer la liste EXACTE des syscalls autorisés.