lkml.org 
[lkml]   [2014]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper
On Wed, Nov 26, 2014 at 09:00:11AM -0600, Eric W. Biederman wrote:
> David Howells <dhowells@redhat.com> writes:
>
> > Eric W. Biederman <ebiederm@xmission.com> wrote:
> >
> >> Ian if we were to merge this I believe you would win the award for
> >> easiest path to a root shell.
> >
> > Is there any particular reason the upcalled program has to be run as root?
> > Could the kernel not run it as something else - perhaps the caller's UID,GID
> > or even something anonymous?
> >
> > Also, call_sbin_request_key() could be given a parameter to call something
> > other than /sbin/request-key, and key_type::request_key could be used.
>
> Fundamentally the upcall needs to happen with enough privileges to do
> the job, and that means running in practice running as root in the
> appropriate context. If we didn't need to gain privileges we wouldn't
> need an upcall.
>
> In the code I was critisizing struct cred was not being changed because
> of what I believe was an ignorance of what task->nsproxy was about and
> is for.
>
> It is straight forward to save off a for a kernel thread from the
> process calling mount and make it responsible for the upcall and use
> that as the parent for all of the containerized upcalls, and we could
> easily run with that threads permissions.
>
> We can't use the context of the triggering user but we instead need to
> use the context of the mounter of the filesystem. As otherwise the
> triggering user can control what is /sbin/request-key and cause problems
> that way.

That makes sense to me. There are three cases I think we care about:

- client idmapper upcall: translates between on-the-wire
"user@domain" names and local uid's/gid's. The results may be
cached and used by other users, and you certainly don't want
the user who happened to trigger the upcall by doing a "ls" to
poison the cache with weird values.

- server-side state recovery call: used to record some
information about which clients hold active state. There's no
"mount" on the server side, but "root in the appropriate
context" still sounds right--we probably want to save the
context of whoever started the server. One extra thread per
server would certainly be no big deal, so if that's how we
need to save the context, fine.

- client request-key call: this isn't actually implemented yet
and I don't feel like I understand it.

--b.


\
 
 \ /
  Last update: 2014-11-27 00:41    [W:0.047 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site