Messages in this thread | | | Subject | Re: [patch 00/13] devtmpfs patches | From | Stephen Smalley <> | Date | Wed, 13 May 2009 08:22:22 -0400 |
| |
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
| |