[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.20.1612201129320.19203@cbobk.fhfr.pm>
Date: Tue, 20 Dec 2016 11:31:57 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
cc: NeilBrown <neilb@...e.com>, kernel-hardening@...ts.openwall.com,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/4] make call_usermodehelper a bit more "safe"
On Tue, 20 Dec 2016, Jiri Kosina wrote:
> 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.
If we want to make usermod helper really secure, perhaps the best way to
go would be to completely nuke it and handle everyhting in udev; that'd be
quite some work though, especially so that we don't break all the corner
cases of module autoloading (request_module() and such).
Thanks,
--
Jiri Kosina
SUSE Labs
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.
