Messages in this thread | | | Subject | Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks | From | Valdis.Kletnieks@vt ... | Date | Wed, 19 Apr 2006 14:50:40 -0400 |
| |
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..." [unhandled content-type:application/pgp-signature] | |