On Monday 02 June 2008 14:32:46 Matthew Wilcox wrote: > The point is to resolve pathnames into dev_t + inode in the > context where the rule is set up. Then you can implement (say) > security_inode_permission() without needing to pass in a vfsmount -- all > you need are the inode->i_ino and inode->i_sb->s_dev to do a comparison. Without the vfsmount, when something is mounted in more than once place, you cannot report which of the name aliases a process is accessing. This is unacceptable; the logs would become unusable. With pathname-based, the AppArmor and TOMOYO folks really mean pathname-based, not a hybrid pathname / mount point model. > Yes, if someone mounts /etc onto /etc2/ and has a rule to allow them to > access /etc/shadow, they will then be able to access /etc2/shadow as > well (which they weren't able to under previous apparmour). But I can't > think of a way that permits Something Bad to happen (since the contents > of the file could have been accessed through /etc/shadow *anyway*). Yes, when a security policy specifies different permissions for the same object on different paths, processes are of course limited to the least restrictive of those paths. One consequence of this is that pathname-based models must control who is allowed to create aliases where, of course. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
