En gros, seccomp-bpf est un framework pour réduire la surface d'attaque (ie désarmer l'attaquant) alors que capsicum implique de continuer à faire confiance au noyau pour qu'un appel ne soit pas "dangereux" (par ex. la faille sur vmsplice).
Having a nice, high level, access control semantics is appealing and, one may argue, necessary. When you're designing a sandbox for your application, you may want to say things such as:
I want this process to have access to this subset of the file system.
I want this process to be able to allocate or de-allocate memory.
I want this process to be able to interfere (debug, send signals) with this set of processes.
The capabilities-oriented framework Capsicum takes such an approach. This is very useful.
However, with such an approach it's difficult to assess the kernel's attack surface. When the whole kernel is in your trusted computing base "you're going to have a bad time", as a colleague recently put it.
Now, in that same dimension, at the other end of the spectrum, is the "attack surface reduction" oriented approach. The approach where you're close to the ugly guts of implementation details, the one taken by Seccomp-BPF.
[^] # Re: Et sinon il y a SELinux
Posté par Pinaraf . En réponse au journal Seccomp, une sandbox intégrée au noyau Linux.... Évalué à 4.
Le blog des développeurs de chrome est très intéressant à ce sujet : http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html
En gros, seccomp-bpf est un framework pour réduire la surface d'attaque (ie désarmer l'attaquant) alors que capsicum implique de continuer à faire confiance au noyau pour qu'un appel ne soit pas "dangereux" (par ex. la faille sur vmsplice).