[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k2b0wus6.fsf@notabene.neil.brown.name>
Date: Fri, 16 Dec 2016 12:02:33 +1100
From: NeilBrown <neilb@...e.com>
To: Greg KH <gregkh@...uxfoundation.org>, kernel-hardening@...ts.openwall.com
Cc: linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/4] make call_usermodehelper a bit more "safe"
On Thu, Dec 15 2016, Greg KH wrote:
> Hi all,
>
> Here's a proof-of-concept patch series that tries to work to address the
> issue of call_usermodehelper being abused to have the kernel call any
> userspace binary with full root permissions.
>
> 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.
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).
If that is a credible threat scenario, it seems to me that the simplest
mitigation is to have call_usermodehelper always call a single
compiled-in path - e.g. /sbin/usermode-helper - and rely on that
program to validate argv[0] and call it if it is deemed safe.
i.e. get the policy out of the kernel.
Just a thought,
NeilBrown
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
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.
