Messages in this thread | | | Subject | Re: [patch 00/13] devtmpfs patches | From | Stephen Smalley <> | Date | Wed, 13 May 2009 08:57:51 -0400 |
| |
On Wed, 2009-05-13 at 14:58 +0200, Kay Sievers wrote: > On Wed, May 13, 2009 at 14:22, Stephen Smalley <sds@tycho.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
| |