On Thu, Aug 29, 2019 at 10:01 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Joe Conway <mail@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.
