|| ||Stephen Smalley <stephen.smalley-AT-gmail.com> |
|| ||Casey Schaufler <casey-AT-schaufler-ca.com> |
|| ||Re: [RFC PATCH 1/2] fs/vfs/security: pass last path component to LSM
on inode creation |
|| ||Tue, 7 Dec 2010 08:43:41 -0500|
|| ||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,
|| ||Article, Thread
On Sun, Dec 5, 2010 at 2:38 AM, Casey Schaufler <firstname.lastname@example.org> wrote:
> The end to which the controls are put does not change the character
> of those controls. If the attribute of the file being used is the
> name component of the name/inode pair in a directory entry than what
> you have is a pathname based control mechanism. It will have all of
> the downsides, including mount points and hard links, that any other
> name based scheme will suffer from.
I think this is a misunderstanding.
The mechanism that Eric is proposing (which btw is something that has
long since been discussed among the SELinux developers and agreed to
in principle, so this is not a point of contention among SELinux
developers) is to allow the last component name of a newly created
file to be used as an optional additional input into the decision
logic for computing the new label of that inode. You can already use
the security contexts of the creating process and the parent directory
along with the type of file (security class) as inputs into that
logic, so this merely adds one additional factor that can be leveraged
by policy writers. It is only used as an input when the file is
created (file access is still based solely on its previously
determined security context) and namespace manipulation has no effect
on it (creating a hard link to the file does not involve this logic,
nor does renaming it nor mounting the containing filesystem
> These "userspace hacks" are no "worse" than restorecond from a
> security perspective. They have the unpleasant characteristic that
> they are outside the control of the primary distributor of SELinux.
> I will admit that the suggested changes will make SELinux better.
> That does not make them any less pathname based.
I don't follow this logic. restorecond and udev relabeling of
kernel-created dev nodes are inherently racy - the file is not created
in the desired security context initially, and must be relabeled by
some userspace component that notices that the file has been created.
Kernel support for incorporating the last component name as an
additional input enables us to label certain files correctly upon
creation and thus avoids that problem entirely. And as for being
outside the control of a given distributor, I think that is both a
fallacy (it is no harder to replace or extend userspace than it is to
replace/extend policy) and irrelevant.
> Initial labeling of objects is critical. There is no point in
> talking about the access control decision if you can't say good
> things about how the label gets set initially.
That's true, and precisely why this is beneficial - it gives us an
additional input to use when labeling objects initially that improves
our accuracy of labeling at file creation time. BTW, this isn't as
novel to SELinux as you seem to think. That fact that we are already
using the parent directory context as an input in computing the
security context of a new files means that our file labeling logic is
already "path-based" in a certain sense. It isn't solely path-based
(either before or after this change), but it is already taking into
account the placement of the file when it is created. This just
refines the granularity at which we can make such decisions.
> My point is roughly centered around the distinction between a Linux
> kernel with SELinux configured and a policy installed and an SELinux
> system with the aforementioned and a complete SELinux runtime that
> includes goodies like restorecond. The former is strictly label based,
> while the latter is definitely not. I really think that you should
> leave the name based bits in userspace unless you are willing to
> accept their general value in the kernel.
SELinux remains label-based in its access control enforcement
mechanism in the kernel even after this change. In any event, you are
free to configure your policy to not use this extension just as you
are free to not ship/run restorecond - there is no real difference
With regard to the pathname hooks, they aren't suitable because they
don't have anything to do with assigning labels to new inodes - they
are about enforcing access control upon file accesses based on the
pathname used to reach the file. That doesn't support what we want.
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.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)