Re: SE-PostgreSQL/Lite Review - Mailing list pgsql-hackers

* Greg Smith (greg@2ndquadrant.com) wrote:
> I personally feel that Steven
> Frost's recent comments here about how the PostgreSQL code makes this
> harder than it should be really cuts to the core of a next step here.
> The problem facing us isn't "is SEPostgreSQL the right solution for
> providing external security checks?"; it's "how can the PostgreSQL code
> be improved so that integrating external security is easier?"  Looking

Thanks for that support, Greg.  This was what I was principally trying
to do with KaiGai and the commitfest patch I reviewed of his last round.
Unfortunately, the committer comments I received on that patch didn't
help us outline a path forward, just declared that the approach in the
current patch wasn't workable.  My, now much more optimistic thanks to
our meeting, view is that the concept of abstracting the access controls
is solid and a necessary first step; but we need to find a better way to
implement it.

Also thanks to our discussion, I've got a much better handle on how
SELinux and the general secuirty community views PostgreSQL (and the
Linux kernel for that matter)- it's an application which consists of a
set of object managers.  That then leads into an approach to address at
least some of Tom's comments:

Let's start by taking the patch I reviewed and splitting up
security/access_control.c along object lines.  Of course, the individual
security/<object>_ac.c files would only include the .h's that are
necessary.  This would be a set of much smaller and much more
managable files which only know about what they should know about- the
object type they're responsible for.

Clearly, code comments also need to be reviewed and issues with them
addressed.  I'm also not a fan of the "skip permissions check"
arguments, which are there specifically to address cascade deletions,
which is a requirment of our PG security model.  I'd love to see a
better solution and am open to suggestions or thoughts about what one
would be.  I know one of KaiGai's concerns in this area was performance,
butas we often do for PG, perhaps we should consider that second and
first consider what it would look like if we ignored performance
concerns.  This would change "skip permissions check" to "what object is
being deleted, and am I a sub-object of that?".  I don't feel like I've
explained that well enough, perhaps someone else could come up with
another solution, or maybe figure out a better way to describe what I'm
trying to get with this.

Regarding the special-purpose shims- I feel there should be a way for us
to handle them better.  This might be a good use-case for column-level
privileges in pg_catalog.  That's pure speculation at the moment tho, I
havn't re-looked at those shims lately to see if that even makes sense.
I don't like them either though, for what it's worth.

Regarding contrib modules- I view them as I do custom code which the
user writes and loads through dlopen() into the backend process- there
should be a way for it to do security "right", but it ultimately has to
be the responsibility of the contrib module.  Admins can review what
contrib modules have been made SELinux/etc aware and choose to install
only those which they trust.

> Maybe Bruce or Steven can champion that work.

See above? ;)  I've had enough of a break from this and our discussion
has revitalized me.  I certainly welcome Bruce's comments, as well as
anyone else.

> I have to be honest and say that I'm not optimistic that this is
> possible or even a good idea to accomplish in the time remaining during
> this release.

While I agree with you, I wish you hadn't brought it up. :)  Mostly
because I feel like it may discourage people from wanting to spend time
on it due to desire to focus on things which are likely to make it into
the next release.  That being said, I don't feel that'll be an issue for
KaiGai or myself, but getting someone beyond us working on this would
really be great, especially yourself and/or Bruce.

> On my side, in addition to helping coordinate everyone pushing in the
> same direction, I'll also continue trying to shake out some sponsorship
> funding for additional work out of the people in this country it would
> benefit.  It seems I'm going to keep getting pulled into the middle of
> this area regularly anyway.

Thank you for that.  I'm planning to do the same and will certainly let
people know, to the extent possible, of anything I'm able to dig up.
Thanks!
    Stephen