lkml.org 
[lkml]   [2009]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch 00/13] devtmpfs patches
From
Date
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



\
 
 \ /
  Last update: 2009-05-13 14:33    [W:0.483 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site