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



KaiGai Kohei wrote:
>> 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 ));
>>     
>
> I noticed the db_xxx:{use} permission remained here. :-)
>   
The example I used above is from an older version of the reference policy.
>   
>> 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?
>>     
>
> It is different from my usage of terms.
> Some of domains are allowed to access the tuple, and others are
> disallowed as the result of access controls using the security
> policy.
>
> I understood the term of "MAC override" to express what actions
> are allowed without any checks based on security policy, as if
> root stuff can ignore DAC checks.
>   
Ya, definitions, definitions :-) Coming from an MLS world, MAC override
meant superseding the B&L policy. In a general sense we use special
authorizations for that (our Security Admin role), while SELinux has a
built in mechanism (mlsdbread)
> Thanks,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/1bdb4cb0/attachment.html