[cap-talk] SELinux vs. capabilities

[Jed Donnelley]

cap-talk,

I'm sorry that I don't have more time at present to contribute
to this thread, but I did at least want to comment (and commit
to follow up) on the highest level issue that jumped out at me,
namely regarding:

At 09:50 PM 7/26/2007, Jonathan S. Shapiro wrote:
>Since SELinux is pretty effective at guarding daemon behavior, it seems
>worthwhile to ask some questions:
>
>   1. Can SELinux behavior be implemented by capabilities?
>   2. What is the relationship, if any, between SELinux and
>      capabilities? Do mandatory controls serve a purpose?
>   3. Can SELinux approximate capability behavior?
>
>...
>Disadvantages:
>
>1. Does not address dynamic or discretionary policy.
>
>
>So, to answer my questions above:
>
>1. SELinux can be implemented on top of capability systems. The current
>constructor/factory model can be used more or less directly.
...

The above two statements, "SELinux does not address discretionary policy.",
and "SELinux can be implemented on top of capability systems." seem
on the surface to be contradictory to me.  I wonder if it might be
worthwhile digging out the source of this apparent contradiction?
I'm focusing on this point because it seems closest to my current
work on the context for Horton - and of course for capabilities
in general.

I suggest this as a seeming contradiction because of course we
know that the dynamics of capabilities demands what I've called
the "Inalienable right to communicate access" (Managing Domains:
http://www.webstart.com/jed/papers/Managing-Domains/#s6 )
That is, if we have our typical Granovetter situation where
A has capabilities to B and C, then A can send the C capability
to B.  Another rewording is that if communication (two way)
is allowed, then communication of permissions (access) is
allowed.  One more final restatement in other terms is that
the structure (discipline, ...?) of capabilities recognizes
that there is no solution to the Communicating Conspirators
problem:

http://www.erights.org/elib/capability/conspire.html

You can of course refer to the tighter statement there
where A = Bob that has a capability (allowing two way
communication) to B = Mallet.  The dilemma that Alice
faces is that she can't give Bob the 'power' (access,
a permission) without allowing Bob to provide that
same 'power' (access, a permission) to Mallet.

Given this nature of capabilities, how can we resolve the
statement that one can implement 'SELinux' on top of
capabilities?  If one were to do so, wouldn't any such
implementation inevitably inherit the 'inalienable
right' to communicate permissions that is a fundamental
aspect of any capability system (and indeed of any
communication system)?

Since Jonathan has looked into this specific example and
made the claim that SELinux (SELinux policies??) can
be implemented on top of capabilities, perhaps he can
explain this seeming contradiction?

--Jed  http://www.webstart.com/jed/