PostgreSQL considers seccomp() filters

Posted Oct 1, 2019 20:07 UTC (Tue) by rweikusat2 (subscriber, #117920)
In reply to: PostgreSQL considers seccomp() filters by Cyberax
Parent article: PostgreSQL considers seccomp() filters

The kernel is a program. Consequently, it has bugs and considering that it's a C program, it should have lots of bugs. In absence of any further information, all non-trivial system calls could be equally exploitable, hence, there's no reason to assume that any particular subset of the available system calls is 'safer' than any other subset. But that's besides the point which was that "we need feature X" and "we are strongly convinced that feature X would be somewhat helpful[*] in hypothetical situation Y" are two very much different things.

[*] Execute arbitrary code in the context of a database server process is a pretty devastating "security breach" in its own right. If this happens, the organisation on whose behalf the database server was running is going to get some serious and possibly even very public problems (eg, as in "all our customer information just got published on the internet").

PostgreSQL considers seccomp() filters

Posted Oct 1, 2019 21:03 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> The kernel is a program. Consequently, it has bugs and considering that it's a C program, it should have lots of bugs.
Indeed. And that's the main motivator for seccomp filtering, to make sure that as little kernel is exposed to a potential attacker as possible.

> hence, there's no reason to assume that any particular subset of the available system calls is 'safer' than any other subset.
Not quite. Objectively some system calls are exercised much less than others. Additionally, some system calls make no sense at all for Postgres (e.g. vm86) and but present a clear threat because they exercise rarely used codepaths and hardware paths.

PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 18:35 UTC (Wed) by nivedita76 (subscriber, #121790) [Link] (4 responses)

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/

PostgreSQL considers seccomp() filters

Posted Oct 25, 2019 5:42 UTC (Fri) by ssmith32 (subscriber, #72404) [Link]

>In absence of any further information, all non-trivial system calls could be equally exploitable, ..

Perhaps, but perhaps not.

Either way, though, the whole point of having people familiar with a particular code base make a list of system calls that they, to the best of their knowledge, is not needed, and are known to give their caller unnecessary privileges, is a way of adding "further information"

And, your assumption now being incorrect, the reasoning based on it should be reworked.