[cap-talk] SELinux vs. capabilities

Toby Murray toby.murray at comlab.ox.ac.uk
Fri Jul 27 15:27:17 EDT 2007


On Fri, 2007-07-27 at 13:14 -0400, Jonathan S. Shapiro wrote:

> > 
> > "Discretionary" depends on your point-of-view. Say there's an object C.
> > C invokes A through a proxy (B) that inserts some value in the
> > invocation so that A can identity which protection domain C resides in.
> 
> Yes. In fact, I have argued on this very list that the defining
> difference between mandatory and discretionary is merely point of view.
> It is sometimes nice to be plagiarized. :-)

I'm glad we agree. My understanding here came from another source,
however, and predates my involvement with cap-talk.

> 
> But I think this is orthogonal to the point I was trying to make.
> 
> An SELinux domain label is just that -- a label. SELinux includes
> mechanisms for changing the label based on runtime behavior. One example
> that comes to mind is behavior when ssh downgrades to the logged-in
> user's initial domain.
> 
> If I wanted to emulate SELinux on Coyotos, one way to do it would be to
> stick the domain ID in the file system capability of the process. The
> file system can then apply the policy. The piece of SELinux that this
> doesn't address is that certain operations can reach back and alter the
> domain ID. In effect, SELinux-style labeling cannot be done without (a)
> interposing on all cross-process invocations and (b) knowing all of the
> object servers involved.
> 
> So there is something going on here that I know how to do in a cap
> system, but which doesn't seem to have any obvious **cost-effective**
> implementation.

These data-points are  definitely worth noting -- things we can do but
aren't easily expressible. That's a good one to remember.

> 
> Part of what is going on here is that UNIX implements a very limited
> number of object protocols: files and directories mostly. A new object
> cannot introduce an arbitrary new protocol in the style of IPC. Further,
> all object servers (e.g. file system, network system) are universally
> trusted to faithfully implement their protocols.
> 
> Under these assumptions, filtering becomes much easier...

Yes. So you get this benefit at an apparently unavoidable cost of a loss
of flexibility.



More information about the cap-talk mailing list