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:	Wed, 13 May 2009 08:57:51 -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 Wed, 2009-05-13 at 14:58 +0200, Kay Sievers wrote:
> On Wed, May 13, 2009 at 14:22, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> 
> > I think you'll actually need to switch credentials around the entire
> > sequence starting from vfs_path_lookup() and going through the
> > vfs_mknod() call in order to avoid any denials from vfs_path_lookup,
> > vfs_mkdir (via create_path), and vfs_mknod.
> >
> > Then the same issue applies to devtmpfs_delete_node() to prevent unlink
> > denials against the current process when a node is removed, similarly
> > wrapping everything from the vfs_path_lookup() through the final
> > delete_path() call.
> 
> Ok, good, will do that. Anything like this to keep in mind when
> creating/removing simple subdirectories?

Yes, any time you call any vfs helper (and thus are subject to the
permission checking calls, both DAC and LSM/SELinux), you need to decide
whether you truly want those permission checks to get applied against
the current process' credentials or whether you should be using
alternate credentials for the call.  If on the other hand you can
perform your operations at a lower level (e.g. direct calls to the
underlying inode operations), then you don't have to be concerned with
the permission checking, but there is still the issue of ownership and
file security labeling for any new files/directories you create, so even
there you may need to establish different credentials to avoid
unwittingly creating those files with the uid/security context of
whatever the current process happens to be.

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