Messages in this thread | | | Date | Mon, 20 Oct 2008 08:27:36 -0400 | From | Shaya Potter <> | Subject | Re: [TOMOYO #11 (linux-next) 01/11] Introduce new LSM hooks where vfsmount is available. |
| |
Kentaro Takeda wrote: > ----- What is this patch for? ----- > > There are security_inode_*() LSM hooks for attribute-based MAC, but they are not > suitable for pathname-based MAC because they don't receive "struct vfsmount" > information. > > ----- How this patch was developed? ----- > > Two pathname-based MACs, AppArmor and TOMOYO Linux, are trying to merge > upstream. But because of "struct vfsmount" problem, they have been unable to e> merge upstream. > > Here are the list of approaches and the reasons of denial.
I know I'm late to the game in this, but as I recently asked about this and didn't get an answer, I'll re-ask my approach.
Why can't you do this
in lookup()
- resolve rules (not for single process, but for all processes) for said path and tag dentry (seem to already have a hook)
in permission()
- check tag based on current security context
in rename(),....
- drop dentry tag and force a lookup next time its used (invalidate dentry)
you then don't have to jump through hoops to handle things like symbolic links as they are handled implicitly.
the only place I can see this approach "failing" (as in different semantics than your approach) is
- hard links within a single namespace and bind mounts shared between namespaces (in that different rules would be resolved for different path names for the same file).
But from a security perspective, both would seem like a very bad idea in general that one would ant to prevent. or to rephrase, why would you want to allow that? What's the benefit in allowing that?
| |