Messages in this thread | | | Date | Tue, 9 Mar 2010 02:18:13 +0100 | Subject | Re: Upstream first policy | From | Luca Barbieri <> |
| |
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).
| |