Message-ID: <9d732d950806020929v1ece55ecobabc418425c1e044@mail.gmail.com>
Date:	Tue, 3 Jun 2008 01:29:33 +0900
From:	"Toshiharu Harada" <haradats@...il.com>
To:	"Evgeniy Polyakov" <johnpol@....mipt.ru>
Cc:	"Miklos Szeredi" <miklos@...redi.hu>, hch@...radead.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, jmorris@...ei.org,
	sds@...ho.nsa.gov, eparis@...hat.com, casey@...aufler-ca.com,
	agruen@...e.de, jjohansen@...e.de,
	penguin-kernel@...ove.sakura.ne.jp, viro@...iv.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 01/15] security: pass path to inode_create

2008/6/3 Evgeniy Polyakov <johnpol@....mipt.ru>:
> On Tue, Jun 03, 2008 at 12:31:14AM +0900, Toshiharu Harada (haradats@...il.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 :)

This is a very important point.

The world of Linux consists of the two pieces, userland and kernel.
Objects have names and inodes. Information flow control need to be
handled using inodes (labels), but pathnames need to be
controlled because objects are represented by names in userland.
Both pieces work together. Vfsmount is a missing piece.

AppArmor and TOMOYO Linux are not claiming they are better MAC for Linux.
(that's how I understood Stephen's words. I am agreed)
So people don't have to eliminate pathname-based MACs.

>> 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 :)
Okay, I'll go and get my coke. ;)

>> 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.
100% agreed.

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

-- 
Toshiharu Harada
haradats@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists