Re: [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper

[Ian Kent]

On Tue, 2014-11-25 at 16:23 -0600, Eric W. Biederman wrote:
> Oleg Nesterov <oleg@xxxxxxxxxx> writes:
> 
> > On 11/25, Oleg Nesterov wrote:
> >>
> >> Let me first apologize, I didn't actually read this series yet.
> >>
> >> But I have to admit that so far I do not like this approach...
> >> probably I am biased.
> >
> > Yes.
> >
> > And I have another concern... this is mostly a feeling, I can be
> > easily wrong but:
> >
> >> On 11/25, Ian Kent wrote:
> >> >
> >> > +static int umh_set_ns(struct subprocess_info *info, struct cred *new)
> >> > +{
> >> > +	struct nsproxy *ns = info->data;
> >> > +
> >> > +	mntns_setfs(ns->mnt_ns);
> >>
> >> Firstly, it is not clear to me if we should use the caller's ->mnt_ns.
> >> Let me remind about the coredump. The dumping task can cloned with
> >> CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand
> >> this enough.
> >
> > And otoh. If we actually want to use the caller's mnt_ns/namespaces we
> > could simply fork/reparent a child which will do execve ?
> 
> That would certainly be a better approach, and roughly equivalent to
> what exists here.  That would even ensure we remain in the proper
> cgroups, and lsm context.
> 
> The practical problem with the approach presented here is that I can
> hijack any user mode helper I wish, and make it run in any executable I
> wish as the global root user.
> 
> Ian if we were to merge this I believe you would win the award for
> easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more
specifically within a container)?

Suppose a user mode helper program scans through the pid list and
somehow picks the correct process pid and then does an
open()/setns()/execve().

Does that then satisfy the requirements?
What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in
kernel (since the caller already knows its pid) but it sounds like
that's not right either.

Ian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/