|| ||Casey Schaufler <casey-AT-schaufler-ca.com> |
|| ||Stephen Smalley <stephen.smalley-AT-gmail.com> |
|| ||Re: [RFC PATCH 1/2] fs/vfs/security: pass last path component to
LSM on inode creation |
|| ||Tue, 07 Dec 2010 06:58:38 -0800|
|| ||Eric Paris <eparis-AT-redhat.com>, penguin-kernel-AT-i-love.sakura.ne.jp,
selinux-AT-tycho.nsa.gov, sds-AT-tycho.nsa.gov, jmorris-AT-namei.org,
hch-AT-lst.de, Casey Schaufler <casey-AT-schaufler-ca.com>|
|| ||Article, Thread
On 12/7/2010 5:43 AM, Stephen Smalley wrote:
> The only real question for this particular patch IMHO is whether the
> changes being made here are sensible from a vfs and fs point of view.
> Most of your comments seem more directed at whether or not SELinux
> should be extended in this manner (i.e. the 2nd patch), and that's a
> question for the SELinux developers, who have already come to
> consensus on the matter.
I will accept that the changes are acceptable to the SELinux
community and that the proposed behavior is perceived as
beneficial within that community.
One of the concerns that has traditionally been raised when new
LSM hooks or changes to existing hooks are proposed is that of
generality. I can think of a number of ways in which the final
component of a pathname could be used to make access control
decisions, but I would not expect to be using them myself. Who
else might you expect to make use of this LSM "enhancement", or
is this something that only SELinux is ever going to want? Is
the component something the LSM should be providing in general,
or is this the only case in which it makes sense?
I think that the LSM interfaces are awfully inconsistent and
quite arbitrary, and that a little bit of consideration about
the possibility of avoiding taking it even further in that
direction is in order, especially when a change is in a fuzzy
area that has been contentious in the past. I remember the
issues that were raised when the AppArmor folks proposed
LSM interface changes, and while the changes proposed today
lack the problems those changes did the same issues need to
be raised and addressed.
In the end, I don't mind an additional parameter I'll not be
using in Smack if it is generally useful.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)