Re: [PATCH] SE-PgSQL/tiny rev.2193 - Mailing list pgsql-hackers

On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhout<kleptog@svana.org> wrote:
> On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
>> > I'm starting to think that there's just no hope of this matching up
>> > well enough with the way PostgreSQL already works to have a chance of
>> > being accepted.
>>
>> What I'm understanding here is the apparent requirement that the SEPostgreSQL
>> implementation be done in a way that a generic SELinux policy that has been
>> written for an operating system and file system can be applied to PostgreSQL
>> without change and do something useful.  I can see merits for or against that.
>> But in any case, this needs to be clarified, if I understand this requirement
>> correctly anyway.
>
> Indeed. My impression was also that there are existing SELinux rules
> and permission concepts already in use and people would like to apply
> them to PostgreSQL, which puts the translation layer inside postgres.
> However, from the postgres side there appears to be a push to make
> unique postgresql SELinux rules and requiring every user of SELinux to
> do the mapping of rights to postgresql specific terms.

I think this is only semi-accurate.  My impression is that a
supposedly generic policy has been written for database objects and
merged into model SE-Linux policy, but I think that was done largely
in the hops of implementing SE-PostgreSQL.  It would be one think if
KaiGai showed up and said, see, there are three other databases that
do this, now we want you to do it too, that would be one thing.  But I
don't think that's the case: I believe that we are the first, which
makes the argument that we have to conform to the "standard" ways of
doing this a lot weaker.

> Specifically, creating SELinux permissions for CREATE LANGUAGE seems
> particularly useless since that's not a data protection issue. The same
> with aggregates, operator classes, etc. ISTM the goal of SELinux is not
> primarily to restrict DDL but mostly to protect the data.

I'd actually be willing to buy that.  If KaiGai wants to take the list
of objects for which SE-PostgreSQL supports grantable permissions and
the list of objects for which $COMPETITOR supports permissions and
implement only the intersection of the two, I think that would be
reasonable.  What I don't think is reasonable is trying to implement,
in the first version of the patch, 50 types of permissions that we
never had before, or on the other hand such a trivial percentage of
what we already do that it's totally useless.

> Personally I find the idea that SELinux permissions need to meet parity with the existing permission structure
> crazy, since it's not going to replace the existing permissions, just supplement them.

Maybe it is crazy, but here are my concerns...

1. If the permissions work in a way that is very different than the
existing permissions, then they need lots and lots of hooks all over
the code.  And nobody except KaiGai understands why those hooks are
where they are instead of somewhere else.  That's going to make it
difficult to maintain.

2. If we add a lot of new kinds of permission checks that PostgreSQL
has never done before, using a framework that none of the committers
understand, how do we verify that they are well-designed (correct,
secure, etc)?  I am fairly well convinced that the design for
row-level security was a really bad design.  Whether I'm right or not,
I think something like that is far too large a feature to add "by the
wayside" in the context of another patch.

3. As far as I can tell, there is a lot of resistance from the
committers who have looked at this patch (Tom, Peter, and maybe Bruce,
though I think his review was not quite so unfavorable) to the idea of
committing it at all.  I don't think they're going to be willing to
work extra-hard to implement security features that are only going to
be useful to people using SE-Linux.

For what it's worth, this problem is not confined to the committers:
SE-PostgreSQL is the only patch that I had people specifically tell me
they didn't want to review because they just didn't care about it.
Frankly, I don't care about it much either: ordinarily, the first and
last thing I do with SE-Linux is shut it off.  What is making me care
even less is the fact that after many revisions we still don't have
anything that can be reviewed with any seriousness.  The initial
versions had so many extra bells and whistles (row-level security,
complex DDL permissions) that they went way beyond basic SE-Linux
support, and now we have a version that is stripped down to the point
where it does barely anything.  I feel like I'm spinning my wheels on
a patch that nobody in the PostgreSQL community really wants anyway.

...Robert