Re: [TOMOYO #11 (linux-next) 01/11] Introduce new LSM hooks wherevfsmount is available.
From: Shaya Potter
Date: Mon Oct 20 2008 - 09:02:19 EST
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/