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
signature.asc
Description: PGP signature