On 2019-08-28 14:30:20 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Maybe I'm missing something, but it's not clear to me what meaningful > > attack surface can be reduced for PostgreSQL by forbidding certain > > syscalls, given the wide variety of syscalls required to run postgres. > > I think the idea is to block access to seldom-used syscalls because > those are exactly the ones most likely to have bugs.
Yea, I can see some benefit in that. I'm just quite doubtful that the set of syscalls pg relies on doesn't already allow any determined attacker to trigger kernel bugs. E.g. the whole sysv ipc code is among those seldomly used areas of the code. As is the permission transfer through unix sockets. As is forking from within a syscall. ... > (We certainly hope that all the ones PG uses are well-debugged...) One would hope, but it's not quite my experience... > Whether the incremental protection is really worth the effort is > debatable, but as long as it's only people who think it *is* worth the > effort who have to deal with it, I don't mind. It seems almost guaranteed that there'll be bug reports about ominous crashes due to some less commonly used syscall being blacklisted. In a lot of cases that'll be hard to debug. After all, we already got such bug reports, without us providing anything builtin - and it's not like us adding our own filter suport will make container solutions not use their filter, so there's no argument that doing so ourselves will reduce the fragility. > Admittedly, you can't get per-subprocess restrictions that way, but the > incremental value from that seems *really* tiny. If listen() has a bug > you need to fix the bug, not invent this amount of rickety infrastructure > to limit who can call it. And, as I mentioned in another email, once you can corrupt shared memory in arbitrary ways, the differing restrictions aren't worth much anyway. Postmaster might be separated out enough to survive attacks like that, but backends definitely aren't. Greetings, Andres Freund
