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


Groups > linux.kernel > #1337855

Re: call_usermodehelper in containers

From Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Newsgroups linux.kernel
Subject Re: call_usermodehelper in containers
Date 2016-02-19 04:10 +0100
Message-ID <r3JCa-71A-1@gated-at.bofh.it> (permalink)
References (9 earlier) <r3n8C-7Ib-11@gated-at.bofh.it> <r3nV0-87u-1@gated-at.bofh.it> <r3qpQ-1xV-13@gated-at.bofh.it> <r3rlU-2aH-3@gated-at.bofh.it> <r3DQ5-2Mf-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

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