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