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, 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.
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
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
