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

Matthew Wilcox
2008-06-02T12:33:20Z

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