Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

Valdis.Kletnieks
2006-04-19T18:51:39Z

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]