**seccomp** (abréviation de **mode de calcul sécurisé**) est une fonctionnalité de sécurité informatique dans le **noyau Linux**. seccomp permet à un processus de passer dans un état "sécurisé" où **il ne peut effectuer aucun appel système sauf**`exit()`, `sigreturn()`, `read()` et `write()` aux descripteurs de fichiers **déjà ouverts**. S'il tente d'effectuer d'autres appels système, le **noyau****terminera** le **processus** avec SIGKILL ou SIGSYS. En ce sens, il ne virtualise pas les ressources du système mais isole complètement le processus de celles-ci.
Le mode seccomp est **activé via l'appel système `prctl(2)`** en utilisant l'argument `PR_SET_SECCOMP`, ou (depuis le noyau Linux 3.17) via l'appel système `seccomp(2)`. Le mode seccomp était activé en écrivant dans un fichier, `/proc/self/seccomp`, mais cette méthode a été supprimée en faveur de `prctl()`. Dans certaines versions du noyau, seccomp désactive l'instruction x86 `RDTSC`, qui renvoie le nombre de cycles de processeur écoulés depuis la mise sous tension, utilisée pour la synchronisation de haute précision.
**seccomp-bpf** est une extension de seccomp qui permet **le filtrage des appels système en utilisant une politique configurable** implémentée à l'aide de règles de filtre de paquets Berkeley. Il est utilisé par OpenSSH et vsftpd ainsi que par les navigateurs Web Google Chrome/Chromium sur Chrome OS et Linux. (À cet égard, seccomp-bpf atteint une fonctionnalité similaire, mais avec plus de flexibilité et de meilleures performances, à l'ancien systrace - qui semble ne plus être pris en charge pour Linux.)
Dans ce mode, **Seccomp ne permet que les appels système**`exit()`, `sigreturn()`, `read()` et `write()` aux descripteurs de fichiers déjà ouverts. Si un autre appel système est effectué, le processus est tué en utilisant SIGKILL.
**Seccomp-bpf** est pris en charge par **Docker** pour restreindre les **appels système** des conteneurs, réduisant ainsi efficacement la surface d'attaque. Vous pouvez trouver les **appels système bloqués** par **défaut** dans [https://docs.docker.com/engine/security/seccomp/](https://docs.docker.com/engine/security/seccomp/) et le **profil seccomp par défaut** peut être trouvé ici [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json).\
Vous pouvez exécuter un conteneur Docker avec une **politique seccomp différente** avec:
Si vous voulez par exemple **interdire** à un conteneur d'exécuter certains **appels système** tels que `uname`, vous pouvez télécharger le profil par défaut depuis [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json) et simplement **supprimer la chaîne `uname` de la liste**.\
Si vous voulez vous assurer qu'**un binaire ne fonctionne pas à l'intérieur d'un conteneur Docker**, vous pouvez utiliser strace pour lister les appels système utilisés par le binaire, puis les interdire.\
Dans l'exemple suivant, les **appels système** de `uname` sont découverts:
Si vous utilisez **Docker uniquement pour lancer une application**, vous pouvez **profil**er avec **`strace`** et **autoriser uniquement les appels système** dont elle a besoin.