PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 22:21 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: PostgreSQL considers seccomp() filters by rweikusat2
Parent article: PostgreSQL considers seccomp() filters

> there's no way to determine if restricing the set of allowed system calls to a certain subset of the set of available system calls will actually reduce the number of exploitable errors a prospective attacker could try to utilitze, let alone reduce it to zero.
This is just nonsense. Reducing amount of code exposed to attacker reduces the chances that an exploitable bug will be accessible to them.

> There's some outright paradoxical reasoning in here: seccomp is supposed to defend against the issue that it's conjectured to be impossible to determine if the implementation of a given system call is free of exploitable errors
You clearly live in a fantasy world. The seccomp sandboxing is designed to prevent access to as much of the attack surface as possible. This automatically makes sure that the probability of an exploit goes down.

Note the word "probability". This is not prevention, it's mitigation.

History shows that this approach actually works in practice. Even the misguided SELinux has prevented multiple exploitable bugs.

PostgreSQL considers seccomp() filters

Posted Oct 3, 2019 17:04 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

I seem to live in a fantasy world called 'reality',

https://en.wikipedia.org/wiki/Seccomp

PostgreSQL considers seccomp() filters

Posted Oct 4, 2019 8:43 UTC (Fri) by cyphar (subscriber, #110703) [Link]

The default seccomp rules that Docker/LXC/cri-o/etc specify have blocked more than 95% of kernel 0day exploits in the past 6 years or so[1], purely by blocking esoteric syscalls and strange flags. There is clear and undeniable evidence that even a very generic seccomp profile does help protect systems running untrusted workloads against kernel bugs.

(As an aside, note that Docker doesn't user user namespaces by default, LXC has been protected against even more exploits. But that's a very different topic.)

[1]: https://docs.docker.com/engine/security/non-events/