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

[Toshiharu Harada]

2008/6/3 Evgeniy Polyakov <johnpol@xxxxxxxxxxx>:
> On Tue, Jun 03, 2008 at 01:29:33AM +0900, Toshiharu Harada (haradats@xxxxxxxxx) wrote:
>> > 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.
>
> They can, if really want, to get vfsmount.
>
> A hint: there is security_sb_check_sb() and security_sb_post_addmount().
> Store that vsmount in private cache, search the very root dentry for any inode
> inside that cache of vfsmounts and get a pointer. Looks a bit ugly
> though, and slower (really a bit), but it can solve a problem.
> It is also possible to implement own path cache isntead of using dentry
> cache, since apparently dentry is not needed neither to apparmor nor to
> tomoyo, but path info (in own format). And that will be even better
> solution, since it will be exactly what selinux does with its data.
> Only to different objects. This will complicate move/rename and other
> pathname manipulation. There are of course underwater rocks, but they
> can be worked out with existing inode-biased approach.
>
> --
>        Evgeniy Polyakov

Actually, another option has been suggested last month.
http://lkml.org/lkml/2008/4/9/93

Miklos' patches seem to me well suited after vfs cleanup jobs, but...

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