Re: [patch 00/13] devtmpfs patches

[Stephen Smalley <sds@tycho.nsa.gov>]

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@tycho.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