Ogni operazione eseguita da un processo Linux passa attraverso il kernel tramite una system call. Quando un processo vuole aprire un file, creare un processo o usare la rete, deve sempre chiedere al kernel tramite una chiamata di sistema.
Operation not permittedQuesto significa che anche un processo root o dotato di capability può essere ulteriormente limitato a livello di system call. Seccomp aggiunge quindi un livello di protezione molto importante, soprattutto nei container.
Docker applica automaticamente un profilo seccomp di default ai container. Vediamo un esempio concreto di system call bloccata.
Avviamo un container Ubuntu:frank@debian:~$ docker run -it ubuntu bash
root@container:/#root@container:/# apt update
root@container:/# apt install -y keyutils
root@container:/# keyctl show
Operation not permitted
root@container:/# exitIl comando keyctl utilizza la system call keyctl().Il profilo seccomp di default di Docker blocca questa chiamata di sistema, quindi il kernel la rifiuta.
Se avviamo il container disabilitando seccomp:frank@debian:~$ docker run -it \
--security-opt seccomp=unconfined \
ubuntu bashroot@container:/# apt update
root@container:/# apt install -y keyutils
root@container:/# keyctl showIn questo caso la system call non viene più filtrata da seccomp.
Questo esempio dimostra che seccomp agisce esclusivamente a livello di system call. Anche se il processo è root all’interno del container se una chiamata non è consentita dal profilo seccomp il kernel la blocca con Operation not permitted.
Seccomp non è l’unico livello di sicurezza del kernel. Anche le capabilities e gli LSM come AppArmor su Ubuntu o Debian possono bloccare un’operazione. Tuttavia seccomp agisce esclusivamente a livello di system call indipendentemente dai privilegi del processo.
