From: Greg KH <gregkh@linuxfoundation.org>
To: Jiri Kosina <jikos@kernel.org>
Cc: NeilBrown <neilb@suse.com>,
kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/4] make call_usermodehelper a bit more "safe"
Date: Tue, 20 Dec 2016 10:27:34 +0100 [thread overview]
Message-ID: <20161220092734.GA12200@kroah.com> (raw)
In-Reply-To: <alpine.LRH.2.00.1612191428060.15543@gjva.wvxbf.pm>
On Mon, Dec 19, 2016 at 02:34:00PM +0100, Jiri Kosina wrote:
> On Fri, 16 Dec 2016, Greg KH wrote:
>
> > > You seem to be targeting a situation where the kernel memory can be
> > > easily changed, but filesystem content cannot (if it could - the
> > > attacker would simply replace /sbin/hotplug).
> >
> > Correct, like an embedded system with a read-only system partition, or
> > for when some kernel bug allows for random memory writes, yet privilege
> > escalation is hard to achieve for your process.
>
> 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.
thanks,
greg k-h
next prev parent reply other threads:[~2016-12-20 9:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 18:50 [RFC 0/4] make call_usermodehelper a bit more "safe" Greg KH
2016-12-14 18:50 ` [PATCH 1/4] kmod: make usermodehelper path a const string Greg KH
2016-12-14 18:50 ` [PATCH 2/4] drbd: rename "usermode_helper" to "drbd_usermode_helper" Greg KH
2016-12-14 18:50 ` [PATCH 3/4] Make static usermode helper binaries constant Greg KH
2016-12-14 19:11 ` [kernel-hardening] " Greg KH
2016-12-14 20:29 ` Rich Felker
2016-12-14 20:54 ` Greg KH
2016-12-15 17:54 ` Greg KH
2016-12-15 20:51 ` Daniel Micay
2016-12-15 21:18 ` Greg KH
2016-12-16 0:05 ` Daniel Micay
2016-12-16 0:14 ` Daniel Micay
2016-12-14 18:51 ` [RFC 4/4] Introduce CONFIG_READONLY_USERMODEHELPER Greg KH
2016-12-14 20:31 ` Kees Cook
2016-12-14 20:57 ` Greg KH
2016-12-14 19:25 ` [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe" Mark Rutland
2016-12-14 20:16 ` Kees Cook
2016-12-14 21:28 ` Jason A. Donenfeld
2016-12-14 23:16 ` Greg Kroah-Hartman
2016-12-16 1:02 ` NeilBrown
2016-12-16 12:49 ` Greg KH
2016-12-19 13:34 ` Jiri Kosina
2016-12-20 9:27 ` Greg KH [this message]
2016-12-20 10:27 ` Jiri Kosina
2016-12-20 10:31 ` Jiri Kosina
2016-12-20 10:48 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161220092734.GA12200@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jikos@kernel.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox