Re: Upstream first policy

[Luca Barbieri <luca.barbieri@gmail.com>]

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).