> On Tue, Jun 03, 2008 at 01:29:33AM +0900, Toshiharu Harada (
haradats@gmail.com) 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
