linux-kernel - Re: [RFC 0/4] make call_usermodehelper a bit more "safe"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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