PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 18:35 UTC (Wed) by nivedita76 (subscriber, #121790)
In reply to: PostgreSQL considers seccomp() filters by rweikusat2
Parent article: PostgreSQL considers seccomp() filters

Yes, this seems kind of superfluous for something like PostresSQL. That is most likely going to be THE thing that the server is doing anyway. Compromising it means its game over already. It could be useful for small stuff like eg ntpd, to prevent a bug in ntpd being escalated into a compromise of the database process, but the other way is just brain-dead.

PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 21:19 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (3 responses)

In theory, this would make more sense. But in practice, it's just build on the same, shaky foundation: A single, exploitable bug is sufficient for such a compromise. And for as long as there's no guaranteed way to determine that the code implementing a certain system call has no exploitable bugs and won't ever have exploitable bugs (system call implementations change), 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.

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 but in order to use seccomp sensibly, ie not in a "fire a shotgun in the dark at hope that some of the projectiles hit something" mode of operation, this very information would need to be known.

The best one could sensibly use this for is to block access to system calls known to be exploitable until a fix becomes available. Or for its original purpose: Run unknown code in a sandbox which is supposed to be prohibited from doing certain things, eg, most file system manipulations.

PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 22:21 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> 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/