From: Linus Torvalds on


On Mon, 8 Mar 2010, Rik van Riel wrote:
>
> > But that thing is _independent_ from the other totally unrelated issue,
> > namely the fact that "/etc/passwd" is a special name in the namespace. In
> > other words, there is "content security", but then there is also
> > "namespace security".
>
> ... what exactly does the namespace security protect against?
>
> What is the threat model that the namespace security protects
> against, which is not protected by the content based security?

Umm? Seriously?

What is _any_ security all about? You try to limit the opportunity for
damage, accidental or not.

So let's take a trivial example. Let's say that you are root, and you edit
/etc/shadow by hand. I've done it, you've probably done it, it's not
rocket science. Now, you do it using any random editor, and most likely
it's going to write the new file into a temp-file, and then rename that
temp-file over the old file (perhaps creating a backup of the old file
depending on editor and settings).

Now, think about what that implies for a moment. Especially consider the
case that there were ACL's ("inode-based security") on the old /etc/passwd
or /etc/shadow file that got moved away as a backup. What happened to
those ACL's when you edited the file using a random editor?

Now, do you see what the difference between pathname-based and inode-based
security is? Do you realize how if anybody wants to track accesses to
/etc/shadow, they are not going to be interested in the _old_ backup copy
of /etc/shadow?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kyle McMartin on
On Mon, Mar 08, 2010 at 11:32:16AM -0800, Linus Torvalds wrote:
> But whatever. The fact is, Ubuntu uses it. We'll merge it.
>

I'd be ever so thrilled if you'd merge utrace in that case...

cheers, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Al Viro on
On Tue, Mar 09, 2010 at 12:15:54AM +0000, Al Viro wrote:
> On Mon, Mar 08, 2010 at 03:37:38PM -0800, Linus Torvalds wrote:
>
> > Of course, you can make /etc unwritable, and that is indeed the
> > traditional UNIX model of handling namespace security: by just
> > implementing it as "content security" of the directory.
> >
> > The sgid and sticky bits can be used to further try to make it more
> > fine-grained (exactly becuase it is _not_ sufficient to say "you can't
> > read or write this directory" on a whole-directory basis), and obviously
> > SELinux has extensions of its own too.
>
> But that's not what the apparmor et.al. are doing. If you want (and that's
> not obviously a good thing) fine-grained access control for directory
> entries, it would at least make some sense. Prohibitively pricy, probably,
> but that's a separate story. But they are *NOT* protecting /foo/bar directory
> entry when you want to protect /foo/bar/baz/barf; it doesn't go up towards
> root.
>
> And if you *do* protect each ancestor and try to keep granularity, you'll
> end up with complexity from hell.

BTW, if you actually look at apparmor (I'd suggest tomoyo, but I'm not _that_
sadistic), you'll see how seriously do they take pathname-based *anything*.
LSM hooks for namespace operations (you know, mount, umount) are lousy, but
they exist. Not used by apparmor.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Luca Barbieri on
I think the point is actually that, ideally, content-based security is
for _reads_, while path-based security is for _writes_:

For example, in the /etc/shadow case:
1. Unprivileged users must not be able to know the _content_ of the
file (or of any copy of it)
2. It doesn't matter at all if anyone modifies a private copy of the
file (with the same content, but not the same path)
3. Unprivileged users must not change the data the /etc/shadow _path_
is associated with
4. It doesn't matter at all if anyone reads a file that happens to be
at /etc/shadow while not containing shadow passwords (with the same
path, but different content)

So I think we should enforce label/inode-based content security on
reads, but we should enforce path/dentry-based security on writes.

In particular, doing a write on a file, and moving a file to that same
path ought to have exactly the same security checks, since the
user-visible effect is the same.

The unix model is broken regarding this, since one will depend on the
write permissions on the file inode, and the other on the directory.
Ideally, both should depend on the write permissions of the _dentry_
(there would need to be a concept of default dentry permissions for a
directory).

The only thing that breaks this are hard links, since they allow to
change the data associated with multiple unknown dentries in a single
operation. However, completely disallowing writes to inodes with
multiple links solves the problem, and shouldn't require fundamental
(or any) userspace changes (of course, this is to be done by the
security module, not by the generic vfs).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Al Viro on
On Tue, Mar 09, 2010 at 02:18:13AM +0100, Luca Barbieri wrote:
> 4. It doesn't matter at all if anyone reads a file that happens to be
> at /etc/shadow while not containing shadow passwords (with the same
> path, but different content)

What the hell are you smoking?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/