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"

----- 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
Please read the FAQ at