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.

My representation might be confusable. What I would like to say was that
it is "unclear" whether the security policy maintainer can accept
definitions of object classes and permissions "as-is" we discussed here,
so I would like to implement them at the second or later phase.
It never means SELinux does not accept PostgreSQL specific permissions
due to the its characteristic features. In fact, SELinux already provides
db_blob object class and corresponding permissions to describe access
control policies on largeobjects.

As you said bellow, SELinux have several db_xxx object classes (it neans
object classes for various kind of database objects) and allows DBMSs to
choose a part of them.

In addition, the security policy developer understand each RDBMS's have
its characteristics, such as largeobjects and loadable C-libraries, so
their security policy also should be developed for each object manager,
although definitions of object classes and permissions can/cannot be shared.

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

I also think the SE-PostgreSQL should support its object classes and
permissions on its characteristic features and the intersection of
the two RDBMSs.

The reason why I dropped most of permission checks was that SE-PgSQL
has been pointed out its patch scale several times in the v8.4 development
cycle, and suggested to drop all the permission check which does not
have 1:1 relationship with the existing pg_xxx_aclcheck().

If we can make clear what should be/should not be implement at the first
patch, I'll modify my patch set again.

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

Linux is a former case example in success. It puts various kind of security
hooks (called LSM; Linux Security Module) rather than existing permissions.
All the interfaces are designed not to give any side effects when security
module (such as SELinux) is disabled, and source code comments explicitly
introduce where/when the hooks should be invoked and what arguments should
be given and what results should be returned.
Needless to say, most of Linux kernel developers are not also security
experts, but its development cycles works well.

In addition, smaller number of security hooks are generally considered
better security design, so these are deployed on primordial routines
these are seldom modified.

In addition, I (and NEC) can provide our capability to the PostgreSQL
community to keep these security features work correctly.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>