Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1337895

Re: call_usermodehelper in containers

Show all headers | View raw

On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote:
> On 2016/02/19 5:45, Eric W. Biederman wrote: 
> > Personally I am a fan of the don't be clever and capture a kernel
> > thread
> > approach as it is very easy to see you what if any exploitation
> > opportunities there are.  The justifications for something more
> > clever
> > is trickier.  Of course we do something that from this perspective
> > would
> > be considered ``clever'' today with kthreadd and user mode helpers.
> > 
> 
> I read old discussion....let me allow clarification  to create a
> helper kernel thread 
> to run usermodehelper with using kthreadd.
> 
> 0) define a trigger to create an independent usermodehelper
> environment for a container.
>    Option A) at creating some namespace (pid, uid, etc...)
>    Option B) at creating a new nsproxy
>    Option C).at a new systemcall is called or some sysctl,
> make_private_usermode_helper() or some,
>   
>   It's expected this should be triggered by init process of a
> container with some capability.
>   And scope of the effect should be defined. pid namespace ? nsporxy ?
> or new namespace ?
> 
> 1) create a helper thread.
>    task = kthread_create(kthread_work_fn, ?, ?, "usermodehelper")
>    switch task's nsproxy to current.(swtich_task_namespaces())
>    switch task's cgroups to current (cgroup_attach_task_all())
>    switch task's cred to current.
>    copy task's capability from current
>    (and any other ?)
>    wake_up_process()
>    
>    And create a link between kthread_wq and container.

Not sure I quite understand this but I thought the difficulty with this
approach previously (even though the approach was very much incomplete)
was knowing that all the "moving parts" would not allow vulnerabilities.

And it looks like this would require a kernel thread for each instance.
So for a thousand containers that each mount an NFS mount that means, at
least, 1000 additional kernel threads. Might be able to sell that, if we
were lucky, but from an system administration POV it's horrible.

There's also the question of existence (aka. lifetime) to deal with
since the thread above needs to be created at a time other than the
usermode helper callback.

What happens for SIGKILL on a container?

> 2) modify call_usermodehelper() to use kthread_worker
> ....
> 
> It seems the problem is which object container private user mode
> helper should be tied to.
> 
> Regards,
> -Kame

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: call_usermodehelper in containers Ian Kent <raven@themaw.net> - 2016-02-11 01:20 +0100
  Re: call_usermodehelper in containers ebiederm@xmission.com (Eric W. Biederman) - 2016-02-18 04:10 +0100
    Re: call_usermodehelper in containers Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2016-02-18 05:00 +0100
      Re: call_usermodehelper in containers Ian Kent <raven@themaw.net> - 2016-02-18 07:40 +0100
        Re: call_usermodehelper in containers Ian Kent <raven@themaw.net> - 2016-02-18 08:40 +0100
          Re: call_usermodehelper in containers ebiederm@xmission.com (Eric W. Biederman) - 2016-02-18 22:00 +0100
            Re: call_usermodehelper in containers Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2016-02-19 04:10 +0100
              Re: call_usermodehelper in containers Ian Kent <raven@themaw.net> - 2016-02-19 06:40 +0100
                Re: call_usermodehelper in containers Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2016-02-19 10:40 +0100
                Re: call_usermodehelper in containers Ian Kent <raven@themaw.net> - 2016-02-20 04:30 +0100
            Re: call_usermodehelper in containers Ian Kent <raven@themaw.net> - 2016-02-19 06:20 +0100

csiph-web