Re: [patch 01/15] security: pass path to inode_create

[Andreas Gruenbacher <agruen@suse.de>]

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