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

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Tue, Jun 03, 2008 at 12:31:14AM +0900, Toshiharu Harada (haradats@gmail.com) wrote:
> > This is a really interesting flame, can you proceed,
> > we will run for cola and peanuts :)
> 
> Let me quote a message by Chris Wright from LSM ml:
> "You cannot discover the path used to access an inode without knowing
> both the dentry and the vfsmount objects. "

Depending on what path you really want. If you want it related to bind
mount, you can (trivially). And even full path with vfsmount with
additional work.

Without any single additional patch on top of security system.

It maybe a bit slower, more complex, duplicate, whatever...
Active security was never a fast solution and was never a compromiss
between those who like it and who do not.

Technically you can be inside created limits and formally do not change
security model, but in practice implement you lovely path based security
checks.

> Another one by Stephen Smalley:
> "Pathname-based security considered harmful.  You want to control access
> to an object, not a name, and the name-to-object mapping is neither
> one-to-one nor immutable."

For those who care exactly about path, they do not want to have security
checks for object, which was there. As addition, selinux
maintainer/architector opinion is a bit biassed :)

> Can you guess when they were posted?
> The answer is December 2003. :)
> Do we need more time? I don't think so.

Apparently we do :)

> I'm viewing Miklos' patches as *enhancements* not only for AppArmor (and
> other pathname-based LSM modules). Everyone can make use of
> information and lose nothing.  Am I too simple minded?

What I wanted to say, is that people who do want to implement theirs
idea, will find a way to do it without breaking other approach.
With additional changes, with more complex approach, more code and
possibly some duplication/optimization/whatever.

So, if people continue to kick theirs head to the wall, they want
exactly that flame, that void talks and so on :)

-- 
	Evgeniy Polyakov