From: warner@rubix.com (Andy Warner)
Date: Tue, 31 Mar 2009 17:11:04 +0200
Subject: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL
In-Reply-To: <49D21FD5.7020600@kaigai.gr.jp>
References: <49D1DA85.1030902@ak.jp.nec.com> <49D1EAE7.8050100@rubix.com>
	<49D21FD5.7020600@kaigai.gr.jp>
Message-ID: <49D23288.2030807@rubix.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



KaiGai Kohei wrote:
> Andy Warner wrote:
>   
>> looks good to me.
>>
>> One minor comment. For the superuser permission, this may be common use 
>> of DBMS's but I believe is not a standard SQL feature. RUBIX has no such 
>> concept, so we would generally ignore that permission. Also, it is 
>> unclear to me what abilities the superuser should have (in the general 
>> sense, not necessarily within sepostgresql).
>>     
>
> It is a request from the pgsql-hackers.
>
> In addition, the permission is well symmetrical with root capability
> on operating system.
> In PostgreSQL, database users with superuser privilege are allowed
> various kind of operating, such as ignoring DAC policy, ignoring
> ownership of database objects, installing shared libraries and so on.
> The db_database:{superuser} enables to control these capabilities.
>
>   
Sounds like our DBA role. Basically, its just a different name. I agree
that the superuser is a common concept in OS's, but note that its use is
often discouraged. I'm note sure introducing it for databases is a great
idea. But, as I said before, we would just ignore it as primarily its
there to satisfy postgresql.
>> Is this just a permission 
>> to override SQL DAC, or does it also give administrative abilities like 
>> setting audit configurations, or "all the above." I think you said 
>> before that it would not allow MAC override, correct?
>>     
>
> SELinux does not allow anyone to override MAC.
> The unconfined domain is allowed anything in the result of access controls.
>   
I am referring to things like:

mlsconstrain { db_tuple } { use select }
(( l1 dom l2 ) or
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsdbread ) or
( t2 == mlstrustedobject ));

where t1 == mlsdbread seems to imply an object is trusted to read
strictly dominating objects. Unless I am missing the meaning here, I
would call this a MAC override. I realize there is no concept of a TE
override, but MLS is part of MAC, no? And, this violates B&L rules. This
is something we would control with a Security Administrator "role". Or,
is this mlsdbread something that is impossible to give to a domain in a
DBMS policy?
>   
>> RUBIX currently has four privileged "roles":
>> Database Administrator: DAC override
>> Security Administrator: MAC override, to some degree. With SELinux much 
>> of this can be done with discrete rules.
>> Audit Administrator: administer audit trail and criteria
>> Database Operator: do the normal day-today administrative DBMS tasks, 
>> like backup.
>>
>> I am curious, if the intended use of the db_database superuser 
>> permission would be an encapsulation of our all of our roles, excluding 
>> the Security Administrator.
>>     
>
> My preference is to adopt common design *as far as possible*.
> If you need finer-grained privileges, please propose it as a characteristic
> part for Trusted RUBIX, as if we did on db_catalog class.
> Anyway, I cannot believe the pgsql-hackers accepts its design changes due
> to the RUBIX's design.
>   
> Thanks,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/25855cfc/attachment.html