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: <ac3eb2510905120810n101dff08yfa945a2ab4b17168@mail.gmail.com>
Date:	Tue, 12 May 2009 17:10:53 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Stephen Smalley <sds@...ho.nsa.gov>
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 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?

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