linux-kernel - Re: [patch 00/13] devtmpfs patches

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:	Tue, 12 May 2009 08:45:44 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	"David P. Quigley" <dpquigl@...ho.nsa.gov>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	Greg KH <gregkh@...e.de>, Jan Blunck <jblunck@...e.de>,
	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...isplace.org>
Subject: Re: [patch 00/13] devtmpfs patches

On Mon, 2009-05-11 at 23:05 +0200, Kay Sievers wrote:
> On Mon, May 11, 2009 at 22:41, David P. Quigley <dpquigl@...ho.nsa.gov> wrote:
> 
> > This however does highlight a problem with the fact that device node
> > labeling isn't being done properly. It should be possible to create this
> > fs with a different name such that it doesn't appear as a tmpfs file
> > system to SELinux. If it appears as a devtmpfs file system then we can
> > specify the root label and labels on the other devices properly in
> > policy.
> 
> That could be done, if it solves this problem. Damn, now we have the
> naming problem back again. :)
> 
> By doing its own fstype, we could also make the auto-mount optional,
> because you could always reach the filesystem anytime later.
> 
> A different fstype has the slight inconvenience, that existing
> userspace needs to be taught to handle it explicitly, while a tmfps is
> already handled automatically because we use tmpfs already today. But
> that may not be too important.
> 
> Thanks a lot for your tests and analysis,

I don't think merely changing the fstype will suffice; that merely lets
us assign a different default security context to inodes in the
filesystem (e.g. device_t vs tmpfs_t), but doesn't address the fact that
use of devtmpfs rather than just udev seems to alter the permission
checking upon an open(2) by mingetty, thereby breaking existing
policies.  Previously mingetty didn't require permissions to mknod; with
devtmpfs, it does.  I'm wondering if devtmpfs is internally performing
operations that ought to be done in kernel context rather than the
context of the userspace process that initiated the open(2).

Also, I was wondering why the existing restorecon -R /dev that is
performed by /etc/rc.sysinit to fix up the security contexts on the
initial /dev tree prior to policy load doesn't seem to be getting
applied when devtmpfs is enabled.  Does devtmpfs pass through setxattr()
requests to the underlying tmpfs mount?

-- 
Stephen Smalley
National Security Agency

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