The inherent fragility of seccomp()

Posted Nov 11, 2017 8:38 UTC (Sat) by alonz (subscriber, #815)
In reply to: The inherent fragility of seccomp() by nix
Parent article: The inherent fragility of seccomp()

I believe the OP meant something subtly different: he wasn't planning to check which syscalls the program uses, rather just what syscalls exist in the kernel. When new syscalls are added - he would add them to the appropriate group in the filters (e.g., if it's a new way to open files, it will be filtered the same as all other open* syscalls). And until this update happens, the filters will ensure glibc (or any other library) will get ENOENT for this new syscall, forcing it to fall back to older syscalls.

In a sense, this just implements a poor-man's-pledge, with the CI system ensuring it evolves together with the kernel (or at least trying to).