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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
