Stephen Smalley wrote:
> On Tue, 2008-07-22 at 13:58 +0200, Andy Warner wrote:
>   
>> Thanks for the info, all is now clear!
>>
>> One more question (from an SELinux newbie!) that has been nagging away
>> at me in regards to the MLS portion of the security context. In the
>> MLS label we have the sensitivity (s0, s1, etc) and the category (c0,
>> c2, etc). Now, as for the categories, its seems clear that in order
>> for label1 to (potentially) dominate label2, then label1 must contain
>> all the categories contained in label2 (i.e., *:c1,c3 can potentially
>> dominate *:c3 where as *:c1 can never dominate *:c3). c0, c1, etc are
>> just names of categories and the only relationship between them is
>> equality or non-equality.
>>
>> But with the sensitivity we have an ordering relationship, e.g., s3 is
>> greater than (or higher, or strictly dominates) s1. The numbering
>> applied to the sensitivity seems to imply (or define?) what that
>> ordering is (s3 is greater than s1 because 3 is greater than 1). Is
>> this numerical ordering a fixed part of the SELinux MLS policy or are
>> the sensitivities simply "names" and how the policy is written defines
>> the ordering. That is, is it possible for a configuration of SELinux
>> MLS to have s0 strictly dominate s3?
>>     
>
> Yes - they are just names and the dominance relationship is defined by
> the policy configuration.
>
> Computing dominance has been handled in a couple of different ways in
> the past:
> 1) Model it as a permission check, with a MLS constraint defined on the
> permission and allowing the type relationship.
> 2) Introduce an interface to the kernel security server to provide
> dominance computations.
>
> See the mailing list archives for more discussion.
>
>   
Is there any requirement that the MLS policy be Bell-LaPadula ? Or can 
it contain arbitrary information flows? (I am guessing the latter). If 
not BL, then does that make dominance relationships only something that 
can be determined for a subset of policy instances? I am assuming the 
LSPP evaluation uses a BL policy instance (?).

Thanks again for the info!

>> My reason for asking is, if the "numerical ordering" of the
>> sensitivities is always true then I can easily write my own functions
>> to perform dominance checks of the MLS labels and those functions do
>> not need to consult the SELinux API. If the sensitivities are just
>> "names" and the policy instance can define any ordering relationship,
>> then any functions written to perform dominance checks must call the
>> SELinux API and seem non-trivial because no dominance check (only) API
>> is provided and the TE behavior will somehow need to be "filtered"
>> from the security check result.
>>     
>
>
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>