linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9b2b86520910211211o30fab495r3a43cc4de9d4e968@mail.gmail.com>
Date:	Wed, 21 Oct 2009 20:11:24 +0100
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, arjan@...radead.org,
	randy.dunlap@...cle.com, rusty@...tcorp.com.au,
	andi@...stfloor.org, dhowells@...hat.com, akpm@...ux-foundation.org
Subject: Re: request_module vs. modprobe blacklist (and security subsystem 
	implications)

On 10/21/09, Eric Paris <eparis@...hat.com> wrote:
> 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

You don't explain why :-/.  All I can see is that you want to correct
the error code from "permission denied" to "not supported".  But
"permission denied" can often cover a variety of issues, no?

I don't see why a module blacklist implemented by extending
modules_disabled should return anything other than "permission
denied".  If you disable modules completely, don't you get "permission
denied"?

And what would be the difference between "permission denied, you do
not have the right to load IPX", and "ipv6 is not supported due to a
policy decision by the system administrator"?  I'd have thought
"permission denied" would suffice for either.

I'm sure I'm missing something important here :-).

Regards
Alan
--
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/