linux-ext4 - 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]

Message-ID: <19713.5738.653711.301814@quad.stoffel.home>
Date:	Thu, 9 Dec 2010 12:48:26 -0500
From:	"John Stoffel" <john@...ffel.org>
To:	Eric Paris <eparis@...hat.com>
Cc:	John Stoffel <john@...ffel.org>, 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,
	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> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
>> >>>>> "Eric" == Eric Paris <eparis@...hat.com> writes:

>> 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?  

Eric> It's entirely a question of labeling and one that was discussed on the
Eric> LSM list in some detail:

Eric> http://marc.info/?t=129141308200002&r=1&w=2

Thank you for pointing me at this discussion.  I'm working my way
through it, but so far I'm not seeing any consensus that this is
really the proper thing to do.  I personally feel this should be in
userspace if at all possible.

Eric> The basic synopsis is that when a new inode is created SELinux
Eric> must apply some label.  It makes the decision for what label to
Eric> apply based on 3 pieces of information.

Eric> The label of the parent inode.
Eric> The label of the process creating the new inode.
Eric> The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc

These seem to be ok, if you're using label based security.  But since
I freely admit I'm not an expert or even a user, I'm just trying to
understand and push back to make sure we do what's good.  And which
doesn't impact non-SElinux users.  

Eric> This patch adds a 4th piece of information, the name of the
Eric> object being created.  An obvious situation where this will be
Eric> useful is devtmpfs (although you'll find other examples in the
Eric> above thread).  devtmpfs when it creates char/block devices is
Eric> unable to distinguish between kmem and console and so they are
Eric> created with a generic label.  hotplug/udev is then called which
Eric> does some pathname like matching and relabels them to something
Eric> more specific.  We've found that many people are able to race
Eric> against this particular updating and get spurious denials in
Eric> /dev.  With this patch devtmpfs will be able to get the labels
Eric> correct to begin with.

So your Label based access controls are *also* based on pathnames?
Right?  

Eric> I'm certainly willing to discuss the security implications of this
Eric> patch, but that would probably be best done with a significantly
Eric> shortened cc-list.  You'll see in the above mentioned thread that a
Eric> number of 'security' people (even those who are staunchly anti-SELinux)
Eric> recognize there is value in this and that it is certainly much better
Eric> than we have today.

>> 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?

Eric> I've actually recently done some perf testing on creating large
Eric> numbers of inodes using bonnie++, since SELinux was a noticeable
Eric> overhead in that operation.  Doing that same test with SELinux
Eric> disabled (or enabled) I do not see a noticeable difference when
Eric> this patch is applied or not.  It's just an extra argument to a
Eric> function that goes unused.

That answers alot of my concerns then.  Not having it impact users in
a non-SELinux context is vitally important to me.

Thanks,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html