call_usermodehelper in containers
kamezawa.hiroyu at jp.fujitsu.com
Fri Feb 19 03:08:04 UTC 2016
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 ?)
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.
More information about the Containers