[cap-talk] SELinux vs. capabilities
Jonathan S. Shapiro
shap at eros-os.com
Sun Jul 29 12:16:06 EDT 2007
On Sun, 2007-07-29 at 00:14 -0700, Jed Donnelley wrote:
> In that case Jonathan's statement that:
> "SELinux can be implemented on top of capability systems."
> would seem to me pretty much meaningless since of course
> all existing SELinux implementations are so built.
It's not quite that bad. I actually think that most of the SELinux
protections can be implemented in a very straightforward and direct way
on top of capabilities.
> Also, his statement that:
> "The current constructor/factory model can be used more or
> less directly."
Hmm. Yes. That probably deserves expansion.
The main protections of SELinux occur at the namespace boundary. That
is: SELinux is primarily concerned with open/search, and much less
concerned with read/write. In particular, SELinux does not attempt to
alter the properties of file descriptors that are communicated over an
IPC subsystem via the unix SENDFD ioctl or similar (that is: capability
To the extent that this is true, confined subsystems are largely
orthogonal to the SELinux controls. The two ideas can be used on
complementary fashion -- confined subsystems can continue to be used for
POLA and application structuring independent of SELinux.
However, this only goes so far. The possibility of capability transfer
across application domain boundaries in SELinux is a significant hole in
> Once the invoke operation on capabilities is exposed,
> then of course capabilities can be communicated as
As with the MLS design, the exposed capability must either be
implemented by a server that is trusted to enforce the policy, or the
invocations must be mediated in a fashion that is knowledgeable about
both the interface and the semantics of the interface.
Third case: intra-compartment in MLS is innocuous. In the same way,
intra-domain invocation in TE/TBAC is innocuous. Fortunately this
includes the overwhelming majority of dynamically observed invocations.
> I guess the question to Jonathan then is whether or
> not invocation of capabilities is permitted in
> his proposed implementation of SELinux semantics
> on top of capabilities using the constructor/factory
I think I answered this above. If not, please ping me again.
More information about the cap-talk