On Tue, 8 May 2012 15:34:29 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Tue, May 08, 2012 at 11:41:52AM -0400, Jeff Layton wrote: > > As a long running daemon, we need to be security-conscious with nfsdcld, > > so let's prune what it can do down to nearly nothing. > > > > We want the daemon to run as root so that it has access to open and > > reopen the rpc_pipefs pipe, but we don't actually need any of the > > superuser caps that come with it. Have it drop all capabilities early > > on. We don't need any of them as long as the fsuid continues to be 0. > > Makes sense to me. > > (In practice, though, surely fsuid=0 is often enough to get everything?) > > --b. > With this, root is basically a user like any other. He has to have explicit permissions to access anything. If another user owns a file and it's not world readable (or group readable by a group to which root is a member), then the process won't be able to read it. Granted, a lot of files are owned by root on a typical machine, but this should still prevent access to any that aren't. This also trims out all of the other extraneous stuff we don't need -- being able to bind to low sockets, traverse directories in which root has no explicit access, chown ability, etc... There are a couple of other approaches we could take here instead: 1) we could run as an unprivileged user and keep CAP_DAC_OVERRIDE. I think that's less safe than what I'm doing here though... 2) we could teach the kernel to create the pipe with a different owner and then run the daemon as a non-root user. That means we'd need some mechanism to tell the kernel what we want that owner to be. I'm not sure how that would work in practice -- maybe a new file in /proc/fs/nfsd ? In any case, I think this is probably good enough for now. This daemon doesn't listen on a socket or anything so any compromise of it would be a local one. Users also don't generally interact with it directly, so you'd need to jump through some hoops in order to break it I'd think. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
