**seccomp** (abreviação de **modo de computação segura**) é uma facilidade de segurança de computador no **kernel Linux**. O seccomp permite que um processo faça uma transição unidirecional para um estado "seguro" onde **ele não pode fazer nenhuma chamada do sistema, exceto**`exit()`, `sigreturn()`, `read()` e `write()` para descritores de arquivo **já abertos**. Se ele tentar fazer qualquer outra chamada do sistema, o **kernel** irá **encerrar** o **processo** com SIGKILL ou SIGSYS. Nesse sentido, ele não virtualiza os recursos do sistema, mas isola completamente o processo deles.
O modo seccomp é **habilitado via a chamada do sistema `prctl(2)`** usando o argumento `PR_SET_SECCOMP`, ou (desde o kernel Linux 3.17) via a chamada do sistema `seccomp(2)`. O modo seccomp costumava ser habilitado escrevendo em um arquivo, `/proc/self/seccomp`, mas esse método foi removido em favor do `prctl()`. Em algumas versões do kernel, o seccomp desativa a instrução x86 `RDTSC`, que retorna o número de ciclos do processador decorridos desde a inicialização, usada para temporização de alta precisão.
**seccomp-bpf** é uma extensão do seccomp que permite **filtrar chamadas do sistema usando uma política configurável** implementada usando regras do Berkeley Packet Filter. É usado pelo OpenSSH e vsftpd, bem como pelos navegadores da web Google Chrome/Chromium no Chrome OS e Linux. (Nesse sentido, o seccomp-bpf alcança funcionalidade semelhante, mas com mais flexibilidade e maior desempenho, ao systrace mais antigo - que parece não ser mais suportado para Linux.)
Neste modo, o Seccomp **só permite as chamadas do sistema**`exit()`, `sigreturn()`, `read()` e `write()` para descritores de arquivo já abertos. Se qualquer outra chamada do sistema for feita, o processo é morto usando SIGKILL
O **Seccomp-bpf** é suportado pelo **Docker** para restringir as **syscalls** dos contêineres, diminuindo efetivamente a área de superfície. Você pode encontrar as **syscalls bloqueadas** por **padrão** em [https://docs.docker.com/engine/security/seccomp/](https://docs.docker.com/engine/security/seccomp/) e o **perfil seccomp padrão** pode ser encontrado aqui [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json).\
Você pode executar um contêiner docker com uma **política seccomp diferente** com:
Se você quiser, por exemplo, **proibir** um contêiner de executar algum **syscall** como `uname`, você pode baixar o perfil padrão em [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json) e simplesmente **remover a string `uname` da lista**.\
Se você quiser ter certeza de que **algum binário não funcione dentro de um contêiner docker**, você pode usar o strace para listar os syscalls que o binário está usando e, em seguida, proibi-los.\
No exemplo a seguir, os **syscalls** de `uname` são descobertos:
Se você está usando o Docker apenas para lançar um aplicativo, você pode fazer um **perfil** dele com o **`strace`** e permitir apenas as chamadas de sistema que ele precisa.
No perfil acima, definimos a ação padrão como "permitir" e criamos uma lista negra para desativar o "chmod". Para ser mais seguro, podemos definir a ação padrão como "rejeitar" e criar uma lista branca para habilitar seletivamente as chamadas do sistema. O seguinte resultado mostra a chamada "chmod" retornando um erro porque está desativada no perfil seccomp.
A partir do Kubernetes 1.19, **o seccomp está habilitado por padrão para todos os Pods**. No entanto, o perfil seccomp padrão aplicado aos Pods é o perfil "**RuntimeDefault**", que é **fornecido pelo tempo de execução do contêiner** (por exemplo, Docker, containerd). O perfil "RuntimeDefault" permite a maioria das chamadas do sistema, bloqueando algumas que são consideradas perigosas ou não geralmente necessárias para contêineres.