On Mon, Jun 02, 2008 at 01:52:21PM +0200, Miklos Szeredi wrote: > Found it: > > http://lkml.org/lkml/2008/4/9/98 > > I did not take part in that discussion and could not have been able to > contribute anyway. From a cursory read of the thread, the idea was > good, but not entirely applicable to apparmor. Or did I miss > something? Sorry, I thought you were on the CC for that. The conversation was somewhat unclear, at least in part because I'd misunderstood the apparmour deny vs allow logic. It was also extremely unhelpful when certain people decided to have a debate about path-name based security. So let me try again. 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. 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*). -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
