[cap-talk] SELinux vs. capabilities - delegation vs. proxying

[Toby Murray]

On Mon, 2007-07-30 at 11:31 -0400, Jonathan S. Shapiro wrote:
> On Sun, 2007-07-29 at 18:01 +0100, Toby Murray wrote:
> > On Sun, 2007-07-29 at 12:16 -0400, Jonathan S. Shapiro wrote:
> > > However, this only goes so far. The possibility of capability transfer
> > > across application domain boundaries in SELinux is a significant hole in
> > > the architecture.
> > 
> > This "hole" is present in all capability systems, yes? Why, then, should
> > it be a problem for SELinux but not for E/Coyotos/Joe-E etc? It appears
> > to me that it is a problem to SELinux if and only if it's also a problem
> > to the latter object-capability platforms.
> 
> Not so. It is a problem because the policy goals are different. It is
> arguably a goal of TE/RBAC as implemented in SELinux to prevent such
> transfers of authority. For most capability systems it is not.
> 
> Note, however, that the membrane pattern is doing exactly the same sort
> of restriction.

If programmed to do so, yes.

> > The only way I can see that it might be a problem for SELinux is that it
> > gives the illusion that it might prevent such transfers, whereas the
> > object-cap platforms have no such pretensions.
> 
> It definitely *can* prevent such transfers. It is not an illusion

I was thinking of passing file descriptors about. I wasn't aware that
SELinux prevented this, but I presume from your response that it does.

> . The
> illusion you refer to concerns the possibility of covert proxy. However,
> a covert proxy instantiated through a penetration requires multiple
> incursions.

Essentially what you're saying is "it's harder to proxy than to just
pass a capability". This is the fundamental reason why Ralph Hartley's
communicating conspirators example is not just of theoretical interest.
Hence, being able to prevent delegation (capability passing by copy)
does indeed give you some benefit, if you're trying to prevent the
sharing of authority.