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

[Andy Warner <warner@xxxxxxxxx>]

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