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

[Jonathan S. Shapiro]

On Mon, 2007-07-30 at 17:00 +0100, Toby Murray wrote:
> 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:
> > > 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.

At present it does not. As I have stated several times, Steve Smalley is
aware of this issue and has chosen not to address it. More precisely:
the LSM mechanism certainly *can* prevent such transfer. I don't think
that the current policies actually do.

Some subsystems actually rely on this mechanism for quasi-confinement. I
believe, off hand, that ssh uses it.

> > . 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.

Yes. In the daemon case I think that it is harder. The reason is that
daemon's are sensitive and closely inspected. It is therefore hard to
embed proxy code in them unnoticed, and penetration is required.

For general user-written code this is not true.

shap