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

[Andy Warner <warner@rubix.com>]

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



Joshua Brindle wrote:
> Andy Warner wrote:
>   
>> 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)
>>     
>
> SELinux doesn't have a built in mechanism, 

By built in mechanism I meant exactly what you describe below. Maybe it
wasn't the best choice of words. The SELinux policy (the MLS policy)
provides a mechanism for the policy writer to assign the ability to
violate B&L information flow. Thus, it would be redundant for the
db_database object to have a permissions for something like "read-up",
etc. If I were to compare that with the Trusted Solaris type policy
mechanism, there was no such mechanism. Our DB would have to perform the
dominance check for an operation, then decide ourselves if the user had
sufficient authorizations to violate B&L. With the current SELinux MLS
policy, all of that is done with one access check. The mac override type
privilege you would see in TSol 8, etc would allow a process to perform
some operation while ignoring the mac policy. This does not help our DB
make a policy decision on a subject as they access a DBMS object.
> mlsdbread is an attribute that you
> give to domains that can violate this particular MLS constraint. Rather than
> having a generic MAC_OVERRIDE like other MLS implementations we went with finer
> grained overrides, you can see them all in kernel/mls.te.
>   
Yep, thats where i got the example above. Our past approach was to
disallow any mac override directly and let them change their session
level. We would then restrict them to read or read/write depending on
their authorizations. The selinux mechanism is better as, by its nature,
it may target specific objects, specific subjects, and specific overrides.
> there are also interfaces in mls.if to do the various overrides (rather than
> adding the attribute yourself), for example if you wanted foo_t to be able to
> read files of all levels you could call:
>
> mls_file_read_all_levels(foo_t)
>
> http://oss.tresys.com/docs/refpolicy/api/kernel_mls.html
>
>   

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