On Tue, 2008-07-22 at 16:30 +0200, Andy Warner wrote: > > > 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 (?). The example security server in SELinux implements a combination of RBAC, TE, and (optional) MLS. The MLS policy is oriented toward BLP but the precise restrictions are defined through policy configuration, in particular the policy writer defines a set of MLS constraints on the Flask classes and permissions that establish what relationship must exist between the subject and object in order for the permission to be authorized. Thus, one could use the MLS engine to implement other hierarchical schemes like Biba instead or a variant of BLP. -- 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.
