linux-kernel - Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation

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:	Thu, 9 Dec 2010 10:05:47 -0500
From:	"John Stoffel" <john@...ffel.org>
To:	Eric Paris <eparis@...hat.com>
Cc:	xfs-masters@....sgi.com, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org,
	cluster-devel@...hat.com, linux-mtd@...ts.infradead.org,
	jfs-discussion@...ts.sourceforge.net, ocfs2-devel@....oracle.com,
	reiserfs-devel@...r.kernel.org, xfs@....sgi.com,
	linux-mm@...ck.org, linux-security-module@...r.kernel.org,
	chris.mason@...cle.com, jack@...e.cz, akpm@...ux-foundation.org,
	adilger.kernel@...ger.ca, tytso@....edu, swhiteho@...hat.com,
	dwmw2@...radead.org, shaggy@...ux.vnet.ibm.com, mfasheh@...e.com,
	joel.becker@...cle.com, aelder@....com, hughd@...gle.com,
	jmorris@...ei.org, sds@...ho.nsa.gov, eparis@...isplace.org,
	hch@....de, dchinner@...hat.com, viro@...iv.linux.org.uk,
	tao.ma@...cle.com, shemminger@...tta.com, jeffm@...e.com,
	serue@...ibm.com, paul.moore@...com,
	penguin-kernel@...ove.SAKURA.ne.jp, casey@...aufler-ca.com,
	kees.cook@...onical.com, dhowells@...hat.com
Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode
 creation

>>>>> "Eric" == Eric Paris <eparis@...hat.com> writes:

Eric> SELinux would like to implement a new labeling behavior of newly
Eric> created inodes.  We currently label new inodes based on the
Eric> parent and the creating process.  This new behavior would also
Eric> take into account the name of the new object when deciding the
Eric> new label.  This is not the (supposed) full path, just the last
Eric> component of the path.

Eric> This is very useful because creating /etc/shadow is different
Eric> than creating /etc/passwd but the kernel hooks are unable to
Eric> differentiate these operations.  We currently require that
Eric> userspace realize it is doing some difficult operation like that
Eric> and than userspace jumps through SELinux hoops to get things set
Eric> up correctly.  This patch does not implement new behavior, that
Eric> is obviously contained in a seperate SELinux patch, but it does
Eric> pass the needed name down to the correct LSM hook.  If no such
Eric> name exists it is fine to pass NULL.

I've looked this patch over, and maybe I'm missing something, but how
does knowing the name of the file really tell you anything, esp when
you only get the filename, not the path?  What threat are you
addressing with this change?  

So what happens when I create a file /home/john/shadow, does selinux
(or LSM in general) then run extra checks because the filename is
'shadow' in your model?  

I *think* the overhead shouldn't be there if SELINUX is disabled, but
have you confirmed this?  How you run performance tests before/after
this change when doing lots of creations of inodes to see what sort of
performance changes might be there?

Thanks,
John
--
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/