linux-kernel - request_module vs. modprobe blacklist (and security subsystem implications)

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-next>] [day] [month] [year] [list]

Message-Id: <1256137348.4443.39.camel@dhcp231-106.rdu.redhat.com>
Date:	Wed, 21 Oct 2009 11:02:28 -0400
From:	Eric Paris <eparis@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	arjan@...radead.org, randy.dunlap@...cle.com,
	rusty@...tcorp.com.au, andi@...stfloor.org, dhowells@...hat.com,
	akpm@...ux-foundation.org
Subject: request_module vs. modprobe blacklist (and security subsystem
 implications)

I recently added a new LSM hook into __request_module(),
security_kernel_module_request().  This new hook checks if a process
should have permission to trigger the loading of a kernel module.  The
attack vector imagined was that some module (IPX for example) has a
vulnerability.  An attack program (which doesn't have permission to load
the IPX module directly) might be able to get the networking stack to
try to autoload the module.  Once loaded the attack program could then
use the larger surface area to exploit the kernel.

We have found that many users disable the IPv6 module by setting their
modprobe config to look like:

blacklist ipv6
install ipv6 /bin/true

The problem is that a number of programs (sendmail, procmail, sshd, and
more) have all been seen to do operations which tried to load the ipv6
module.  These get into request_module(), hit the security hook, and are
obviously denied since the security system doesn't see a need for those
programs to be able to request a module be loaded.

What I really want is a way for the kernel to know that a module has
been disabled and to not even call the security hook.  My thought would
be something like adding the ability to do

echo "ipv6 -l" > /proc/sys/kernel/modules_disabled

which would add "ipv6" to a list of strings.  This list of strings could
be checked in request_module() and if the module was explicitly denied
autoloading ability we wouldn't make the call out to userspace (or the
security hook)

echo "ipv6 +l" > /proc/sys/kernel/modules_disabled

would reenable the ability of a module to be autoloaded.

cat /proc/sys/kernel/modules_disabled

would be a multiline output, first line would be the 0/1 state we know
today, rest of the lines would be the list of modules being denied
autoload.

What do others think?  What's a better way to stop calling out to
userspace looking for the ipv6 module when userspace knows it's
disabled?

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/