On Wed, 19 Apr 2006 11:32:56 PDT, Crispin Cowan said:

> AppArmor initially validates your access at open time, and there after
> you can read&write to it without mediation. AppArmor re-validates your
> access if policy is reloaded, you exec() a new program, you get passed
> the fd from another process, or you call our change_hat() API.
> 
> So, if the file is unlinked or renamed while you have it open, and
> policy says you don't have access to the new name, then:
> 
>     * within the same process you get to keep accessing it until
>           o policy is reloaded by the administrator
>           o you call the change_hat() API
>     * in some other process, either a child or some process you passed
>       an fd to, you don't get to access it because your access gets
>       revalidated

My brain is small, and my eyes glaze over easily... ;)

What happens for the following sequence:

a) Process A does   fd = open("/some/protected");
b) Somebody then does an unlink("/some/protected");
c) A then does a fork/exec, handing the exec'ed process B the open FD 
as its stdin.

What name do you use to re-validate B's access to the data described by
the inode that open file is referencing?

Note that although B can't get any access to the data that A didn't have,
it can still be used to bypass security, because B may be able to *copy* that
data to an area where A couldn't write (presumably because A is in a confined box).

This can be mitigated by saying "A can't fork/exec" - which may not work if
A in fact needs to exec things (webserver CGI comes to mind).  I don't see
any provision for saying "A can only exec B, C, and D and nothing else..."