Introducing seccomp

Imagine it’s 2005 again. There are many Linux computers connected to the Internet all over the world, and most of them are underutilised. Why not donate or sell their spare CPU cycles? However, this means running a third-party code on your precious machine, so security is a great concern. That was the idea behind the CPUshare project ( http://caca.zoy.

org/wiki/CPUShare), an early compute cloud attempt. Secure computing, or seccomp, was this cloud’s security mechanism. Once enabled, it restricted certain processes with four syscalls: read(2) ,

write(2) , _exit(2) and sigreturn(2) . CPUshare project wasn’t a great success, yet seccomp has remained part of the Linux kernel since version 2.6.12. Some years later, Google saw its potential to sandbox browser plug-ins. Four syscalls seemed too strict for this type of software, so another mode, “filter ”, was added. It enabled syscall filtering through classical BPF programs. If you don’t know what they are, think tcpdump filters. A filter could allow the syscall to proceed normally, force an error, or even kill the offending process abruptly with SYSKILL .

Seccomp isn’t the most popular Linux technology, but you’re likely using it without even being aware. It comes with Firefox and Chrome, as well as OpenSSH and vsftpd. Docker applies a default seccomp profile and enables you to create your own with JSON. Seccomp is supported in Flatpack and Snap, and Android has made use of it since 8.0.