[Apparmor-dev] Object Capabilities for AppArmor

[Rob Meijer]

On Thu, November 22, 2007 11:09, Crispin Cowan wrote:

> I've been trying to digest the whole document, but that's taking too
> long, so instead I'll address what I see as issues.
>
> Rob says that he does not want to implement any kind of "do not
> (re)delegate authority" options. Here I disagree.
>
> The issue is that one of the ways that FDs can be delegated is to leave
> them open across exec(). Lots of software legitimately does this. OTOH,
> lots of software accidentally does this, and that has lead to at least
> half a dozen security vulnerability issues in the last 2 years. An
> attacker can thus coax a privileged program into exec'ing something the
> attacker controls, leaving some sensitive FDs open, and thus gain access
> to those FDs.
>
> So I see it as essential for AppArmor to have a switch of some kind to
> determine whether FDs are delegable.
>
> Rob, why do you think it is important that there not be policy controls
> to permit delegation?

The main reason for my oppinion of that is the cooperating conspiritor
problem. We know that the CC problem has no solution, and thus that it
is impossible to fully stop delegation of 'authority'. It is possible to
make delegation hard, but it isn't possible to stop delegation between
comunicating cooperating entities that both want the authority to be
delegated. If you stop permissions from being delegated, the delegating
entity could simply start acting as a proxy in order to work around the
permission passing restrictions. Given this fact I feel that a policy that
alows two entities to comunicate but doesn't allow them to delegate
permissions has no different security properties than a policy that
allows both communication and delegation between the two entities.