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. (We certainly
hope that all the ones PG uses are well-debugged...) That seems fine.
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.
What I don't like about this proposal is that the filter configuration is
kept somewhere where it's not at all hard for an attacker to modify it.
It can't be a GUC, indeed it can't be in any file that the server has
permissions to write on, or you might as well not bother. So I'd throw
away pretty much everything in the submitted patch, and instead think
about doing the filtering/limiting in something that's launched from the
service start script and in turn launches the postmaster. That makes it
(mostly?) Not Our Problem, but rather an independent component.
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, TBH, I'm still wondering why SELinux isn't the way to address this.)
regards, tom lane