On 2019-08-28 14:30:20 -0400, Tom Lane wrote:
> Andres Freund <andres@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
