[Apparmor-dev] Object Capabilities for AppArmor

[Crispin Cowan]

Rob Meijer wrote:
> 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.
>   
I disagree, it does have different security properties, because it makes
different assumptions about the various 'parties' in the situation.

Your analysis is worst-case, where we assume that the delegating program
is fully malicious, and is looking for a way to push the authority out.
In my case, we assume that the delegating party is not cooperating, but
is merely foolish (vulnerable). The delegator is merely accidentally
leaking permissions, and has no intention at all to delegate authority.

It is true that if the delegator has a vulnerability that allows the
attacker to inject and execute arbitrary code, then they become a
cooperating conspirator. The problem is that the "leaking FDs" bug is
more common than the "arbitrary code execution" problem (or at least
occurs independent of it) and so we can gain real, practical security
value from blocking delegation of permission in this way.

> From this I would conclude that any efford spent in implementing measures
> that stop permissions from 'explicitly' being delegated would be a waste of
> time and resources, and in adition to this may result in undue convidence
> in policy that uses these measures, and may give the impression that it
> implements a policy that by fundamental imposibilities could never actualy
> be fully enforced (at least when you take the authority rather than the
> permission view on delegation).
>   
So document the feature to say so.

> Given this, I do agree with you that the accidental delegation on exec is
> a major problem, I however do not agree that it is the delegation itself
> that is the source of the problem, or that in blocking 'explicit'
> delegation there could be a solution.
>
> In my view it is the lack of explicit designation where the problem lies,
> and thus I feel that we should look for a solution in making fd's that are
> passed on exec being passed (or being marked as not being passed) by
> designation in a more explicit way.
>
> I feel that a solution may lay in adding a system call that allows Fd's
> to be designated for passing on exec, and than to 'on exec' mark all
> Fd's of the child process that wern't explicitly designated by the parent
> process as 'leaked' permissions. I don't know if this solution would be
> simple, hard or impossible within the LSM framework, but something along
> this line would be where I feel a solution should be looked for.
>   
There is already such a system call. "man 2 fcntl" and look for the
CLOEXEC flag.

The issue is that some software forgets to set this flag. The major
purpose of AppArmor is to protect against defects in software by using
policy to enforce behavior by vulnerable programs. There is good value
in having an external policy mechanism to prohibit delegating
permissions as a hedge against the software delegating permissions by
mistake.

> Further, where there may be some justification for making Fd passing
> across exec policy based (although I would feel its a bit overkill for the
> problem
> it solves), doing the same for Fd's passed over sockets would I feel be a
> bit to much.
>   
Because of the nature of the API's, it is very easy for software to
mistakenly delegate permission by failing to close on exec, because
delegation across exec is the default behavior unless you block it. In
contrast, delegation over a socket cannot happen by mistake, you must
explicitly pass the FD through the socket. Therefore I am ok with the
idea that our policy control should only apply to passing via exec, and
we can trust that i software delegates over a socket, that it really
meant to do that. If we want to stop delegation by socket, then we need
to block the communication entirely.

> Do you at least agree that it is a designation rather than a delegation
> that is the underlaying problem in the accedentaly passed Fd's?
>   
I assume that "designation" and "delegation" are technical terms in the
OC space, so that just like "authority" means something very specific,
so do "designation" and "delegation". I just don't know what that
meaning is, so I can't answer your question yet.

I've made this complaint before, it is an unfortunate habit of the OC
community to overload the meaning of common words such as "authority",
"permission", and in this case "designation" with specific technical
meanings. It confuses people from outside the community, and because the
technical terms are all common words, it makes it hard to google for.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work