Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Dec 2016 11:27:13 +0100 (CET)
From: Jiri Kosina <>
To: Greg KH <>
cc: NeilBrown <>,,
Subject: Re: [RFC 0/4] make call_usermodehelper a bit more "safe"

On Tue, 20 Dec 2016, Greg KH wrote:

> > Sorry, I really don't get this.
> > 
> > If kernel memory can be easily changed (which is assumed here), why bother 
> > with all this? I'll just set current->uid to 0 and be done.
> Because you don't want your current process to uid 0, you want some
> other program to run as root.  It's quite common for exploits to work
> this way, take a look at how the p0wn-to-own "contests" usually break
> out of sandboxed systems like browsers.

So what kind of sandbox are we talking about here?

namespaces-based sanbox? If you have direct access to kernel memory, you 
can just assign whatever context you want to task_struct's fs struct, and 
you are out of a sandbox.

chroot-based sandbox? Exactly the same argument (you just reset fs->root 
in task_struct).

I stay totally unconvinced that such kind of countermeasure brings any 
value whatsoever. Could you please bring up a particular usecase, where 
you have complete control over kernel memory, and still the only possible 
exploit factor is redirecting usermodhelper? It feels like rather random 
shot into darkness.


Jiri Kosina

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.