[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1242217342.9974.10.camel@localhost.localdomain>
Date: Wed, 13 May 2009 08:22:22 -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 00:55 +0200, Kay Sievers wrote:
> On Tue, 2009-05-12 at 17:54 +0200, Kay Sievers wrote:
> > On Tue, May 12, 2009 at 17:35, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> >
> > > 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);
> >
> > Ah, I see.
>
> Here is the current state of the patch. It would be great, if you can
> have a quick look, if that matches what you meant. It runs fine here,
> but I didn't try any security enforcing software so far, which might run
> into trouble without the credential stuff.
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.
--
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/
Powered by blists - more mailing lists