Re: How would I go about figuring out if two SELinux MLS Levels intersect?

[Darrel Goeddel <dgoeddel@TrustedCS.com>]

Stephen Smalley wrote:
> On Wed, 2008-02-20 at 13:13 -0500, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Wed, 2008-02-20 at 12:25 -0500, Stephen Smalley wrote:
>>>   
>>>> On Tue, 2008-02-19 at 17:13 -0500, Daniel J Walsh wrote:
>>>>     
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> s2:c0-s2:c0.c10 and s2:c9.c10
>>>>>
>>>>>
>>>>> IE How do I do the arbitration/dominance math in Code?
>>>>>       
>>>> (cc'ing the list)
>>>>
>>>> You can model it as a permission check between the two contexts, and
>>>> then write a MLS constraint in policy that requires dominance or
>>>> whatever relationship you want.  Then it is just an avc_has_perm call.
>>>> Same thing that we did for permission check in the pam_selinux code to
>>>> verify that the user's level is within his range.  Or what we talked
>>>> about for applying a permission check in mcstransd to see if the
>>>> requestor is allowed to translate the context.  Not sure that ever got
>>>> implemented in mcstransd though?
>>>>     

I think this is what you are referring to:

http://marc.info/?l=selinux&m=116110364714182&w=2

It doesn't look like that ever got incorporated into mcstransd.  However, the
policy support is there.

>>> Also, just to note:  the MLS dominance logic already exists within
>>> libsepol and within the kernel security server.  We just have to expose
>>> it via an interface.  One way to do that is to express it as a
>>> permission check, where we already have an interface.  Another way would
>>> be to introduce a new interface specifically for that purpose.
>>>   
>> I strongly disagree with exporting the security server logic in this 
>> way, that will just encourage people to implement blp in their 
>> application instead of using the security server interface to do 
>> permission checking. This is based off what I've seen people trying to 
>> do, even within the SELinux community, with respect to MLS.
> 
> Well, as I said, one way to do it is via a permission checking
> interface, and that is what we've done for the user level validation in
> pam_selinux and what we proposed for mcstransd.
> 
> Where that may break down is when you want to actually order a set of
> contexts.  Dave Quigley ran into that in his work to provide a union
> view of a polyinstantiated directory and wanted to be able to decide
> which instance should be the default when there is a conflict in names.
> There you may need an actual MLS dominance interface.  Which is
> MLS-specific, yes, but there will be such applications even if we keep
> them minimized.

The domination check can be faked just like it is in the mcstransd patch.
The big problem is that TE complicates the process.

Let's say we have an "mls" security class with the permissions "dom",
"domby", "eq", and "incomp" along with the following mls constraints:

mlsconstrain mls dom
	(l1 dom l2);

mlsconstrain mls domby
	(l1 domby l2);

mlsconstrain mls eq
	(l1 eq l2);

mlsconstrain mls incomp
	(l1 incomp l2);

You can implement a routine in you app that will create fake contexts
like know_user:known_role:known_type:LEVEL1 and
know_user:known_role:known_type:LEVEL2 where LEVEL1 and LEVEL2 are the
levels you want to compare and make the appropriate avc call to determine
the relationship.  The the non-mls portions of the context must be set up
so that the contexts are valid and TE will never fail for the operations
on the mls class.  The mcstrand patch did such faking.  This works, but
it is not a very elegant solution to the problem.  You can probably
find existing mlsconstraints on various classes to meet your needs without
the "mls" class.  Note that this is policy dependent and does not work
in permissive mode (they will all pass then and your levels will be
incomparable and equal at the same time).

Ordering can be done with a whole lot of comparisons if your set of levels
does not contain disjoint categories (no incomparables)...

You can also take advantage of the format of the raw mls context to create
mls structures and write a function to do the comparisons on those, but that
would be *very* dependent on the mls definitions in the policy and therefore
risky.  It completely blows away the abstraction.  I actually feel bad for
even mentioning that, but there it is.

-- 

Darrel

--
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.