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. > > 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
