[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161214192459.GA16972@leverpostej>
Date: Wed, 14 Dec 2016 19:25:00 +0000
From: Mark Rutland <mark.rutland@....com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
Gengjia Chen <chengjia4574@...il.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [RFC 0/4] make call_usermodehelper a bit more
"safe"
Hi,
On Wed, Dec 14, 2016 at 10:50:00AM -0800, Greg KH wrote:
> The issue is that if you end up getting write access to kernel memory,
> if you change the string '/sbin/hotplug' to point to
> '/home/hacked/my_binary', then the next uevent that the system makes
> will call this binary instead of the "trusted" one.
>
> It does this by moving the location of the binary to be in read-only
> memory. This works for a number of call_usermodehelper strings, as they
> are specified at build or configuration time. But, some subsystems have
> the option to let userspace change the value at runtime, so those values
> can't live in read-only memory.
> So, anyone have any better ideas? Is this approach worth it? Or should
> we just go down the "whitelist" path?
As a general note, I believe the write-rarely / mostly-ro [1] stuff is
meant to cater for this case, but I haven't heard anything on that front
recently (and there doesn't appear to be anything on the KSPP TODO
page).
If that does cater for this case, and if we're able to implement that
generically, that might be nicer than locking down the set of binaries
at build time.
Chen, are you still looking at implementing write-rarely support?
Thanks,
Mark.
[1] http://www.openwall.com/lists/kernel-hardening/2016/11/16/3
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.
