Re: [PATCH] nfsdcld: add support for dropping capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 08, 2012 at 04:03:43PM -0400, Jeff Layton wrote:
> 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,

... including, looking at my Fedora box, /etc/passwd, /etc/shadow, the
entire contents of /usr/bin, all sorts of interesting /proc files....

Sounds like game over?  Maybe not if selinux or something else
intervenes.

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

Sure.

--b.
--
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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux