linux-kernel - Re: [patch 01/15] security: pass path to inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Jun 2008 20:52:23 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Toshiharu Harada <haradats@...il.com>
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

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