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]

Message-Id: <1242142528.31807.80.camel@localhost.localdomain>
Date:	Tue, 12 May 2009 11:35:28 -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>,
	David Howells <dhowells@...hat.com>
Subject: Re: [patch 00/13] devtmpfs patches

On Tue, 2009-05-12 at 17:10 +0200, Kay Sievers wrote:
> On Tue, May 12, 2009 at 14:45, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> 
> > 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.
> 
> It will be its own filesystem type and no longer be auto-mounted in
> initramfs at all. There is an option to request an auto-mount it for
> the case the kernel mounted the rootfs. This is to allow the rescue
> setup to work.
> 
> > 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).
> 
> How may that look like?

I think the issue is that the devtmpfs functions are calling vfs helpers
to create and unlink the device nodes, and those helpers apply
permission checks based on the current process' credentials.  I think a
similar issue arose in sysfs a while ago.  Options are to either bypass
the vfs helpers to avoid that permission checking for what I think are
intended to be kernel-internal operations, or to override credentials
temporarily around the calls to the vfs helpers, ala:
new_cred = prepare_kernel_cred(NULL); 
old_cred  = override_creds(new_cred);
rc = vfs_mknod(...);
revert_creds(old_cred);

> > 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?
> 
> It's a plain tmpfs, nothing different from a manual mounted one, just
> that the kernel has created the instance and remembered the vfs mount
> to put stuff into it, regardless of where is is mounted, or maybe not
> mounted at all.
> 
> Thanks,
> Kay
-- 
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/