linux-kernel - Re: module loading permissions and request

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: <1249937339.2501.80.camel@dhcp231-106.rdu.redhat.com>
Date:	Mon, 10 Aug 2009 16:48:59 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Neil Horman <nhorman@...driver.com>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-security-module@...r.kernel.org, sds@...ho.nsa.gov,
	davem@...emloft.net, shemminger@...ux-foundation.org,
	kees@...ntu.com, morgan@...nel.org, serue@...ibm.com,
	casey@...aufler-ca.com, dwlash@...hat.com
Subject: Re: module loading permissions and request_module permission
 inconsistencies

On Mon, 2009-08-10 at 16:23 -0400, Neil Horman wrote:
> On Mon, Aug 10, 2009 at 03:45:13PM -0400, Eric Paris wrote:

> > 1) remove CAP_SYS_MODULE from the networking code and instead check
> > CAP_NET_ADMIN.  Maybe CAP_NET_ADMIN is already being checked and I'll
> > just remove the capable call altogether but at least I can more
> > intelligently limit the powers of these processes and they will still be
> > root limited according to DAC permissions like they are today.
> > 
> Would this have any adverse effect on how user space sees this working.
> Intuitively I would think that if you wanted to load a module (directly or
> indirectly, via an iptables command or whatnot), you would need CAP_SYS_MODULE
> capabilities on the calling process, not just CAP_NET_ADMIN.  I honestly don't
> know the answer here, I'm just raising the question.

While that might make intuitive sense, it's actually proving to be a bad
idea to use the same capability for direct and indirect module loading
(especially considering we have 125 other places in the kernel where you
can do indirect module loading without any security check)  And believe
me, if someone suggests I move a CAP_SYS_MODULE check down into
__request_module I'll scream about what a horrible idea that is (and
then laugh at them behind their back).

While I think there should be some check in __request_module I don't
think it should be CAP_SYS_MODULE.

CAP_NET_ADMIN at least limits us to root and in all reality to the same
situation everyone is in today.  I just checked every single selinux
domain that grants CAP_SYS_MODULE already grants CAP_NET_ADMIN, so we
can somewhat safely say that nothing (on a fedora system at least) would
break with this change.

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