On Thu, Aug 29, 2019 at 10:01 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Joe Conway <m...@joeconway.com> writes: > > Clearly Joshua and I disagree, but understand that the consensus is not > > on our side. It is our assessment that PostgreSQL will be subject to > > seccomp willingly or not (e.g., via docker, systemd, etc.) and the > > community might be better served to get out in front and have first > > class support. > > Sure, but ... > > > But I don't want to waste any more of anyone's time on this topic, > > except to ask if two strategically placed hooks are asking too much? > > ... hooks are still implying a design with the filter control inside > Postgres. Which, as I said before, seems like a fundamentally incorrect > architecture. I'm not objecting to having such control, but I think > it has to be outside the postmaster, or it's just not a credible > security improvement. It doesn't help to say "I'm going to install > a lock to keep out a thief who *by assumption* is carrying lock > picking tools." >
I recognize this discussion is over but this is a mischaracterization of the intent. Upthread I said: "This may not do it alone, and security conscious integrators will want to, for example, add seccomp filters to systemd to prevent superuser from disabling them. The postmaster and per-role lists can further reduce the available syscalls based on the exact extensions and PLs being used. Each step reduced the surface more and throwing it all out because one step can go rogue is unsatisfying." There are no security silver bullets, each thing we do is risk reduction, and that includes this patchset, whether you can see it or not. Thank you.
