Re: [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner <warner@rubix.com>]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]



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

[-- Attachment #2: Type: text/html, Size: 2126 bytes --]