On Thu, 2008-02-21 at 14:50 -0600, Darrel Goeddel wrote: > 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. Rather than do the latter, we would just introduce libsepol interfaces or kernel selinuxfs interfaces that would leverage the security server MLS logic to perform comparisons. As I mentioned, Dave Quigley previously wrote patches to add that kind of interface to selinuxfs for use by his union directory support for multi-level directories, but it hasn't been upstreamed to date since that work hasn't yet gone upstream (it was experimental and blocked on proper union mount support in mainline). -- Stephen Smalley National Security Agency -- 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.
