Re: [PATCH] SE-PgSQL/tiny rev.2193

Robert Haas wrote:
> 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.
>

FYI Trusted RUBIX already has SELinux integration in their DBMS:
http://www.nsa.gov/research/selinux/list-archive/0807/26900.shtml

They are using the same SELinux object classes that KaiGai developed for 
SE-Postgres.

>> 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.
>

The reason for comprehensively protecting objects isn't necessarily about 
protecting the data in the database but for limiting information flow between 
clients of differing security levels. Eg., if someone top secret can create 
language and use that to pass information down to someone unclassified then 
postgres could be used as an information downgrader illegitimately.

>> 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.
>

I've said it before but I have firsthand knowledge of people wanting/waiting for 
SELinux integration into Postgres (or any open source DBMS)

> 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.
>

That is your (and the communities) prerogative. Linus wasn't very supportive of 
SELinux in the kernel either but it is the only way Linux got an EAL4+ LSPP 
evaluation for use in certain government systems. I personally would love to see 
an open source DBMS evaluated for systems like this because the current state of 
the art is fairly sad.