Re: [PATCH] don't allow CAP_NET_ADMIN to load non-netdev kernelmodules
From: Ben Hutchings
Date: Fri Feb 25 2011 - 14:53:15 EST
On Fri, 2011-02-25 at 11:43 -0800, David Miller wrote:
> From: Ben Hutchings <bhutchings@xxxxxxxxxxxxxx>
> Date: Fri, 25 Feb 2011 19:30:16 +0000
> > On Fri, 2011-02-25 at 11:16 -0800, David Miller wrote:
> >> From: Ben Hutchings <bhutchings@xxxxxxxxxxxxxx>
> >> Date: Fri, 25 Feb 2011 19:07:59 +0000
> >> > You realise that module loading doesn't actually run in the context of
> >> > request_module(), right?
> >> Why is that a barrier? We could simply pass a capability mask into
> >> request_module if necessary.
> >> It's an implementation detail, and not a deterrant to my suggested
> >> scheme.
> > It's not an implementation detail. modprobe currently runs with full
> > capabilities; your proposal requires its capabilities to be limited to
> > those of the capabilities of the process that triggered the
> > request_module() (plus, presumably, CAP_SYS_MODULE).
> The idea was that the kernel will be the entity that will inspect the
> elf sections and validate the capability bits, not the userspace
> module loader.
Yes, I understand that.
> Surely we if we can pass an arbitrary string out to the loading
> process as part of the module loading context, we can pass along
> capability bits as well.
If you want insert_module() to be able to deny loading some modules
based on the capabilities of the process calling request_module() then
you either have to *reduce* the capabilities given to modprobe or create
some extra process state, separate from the usual capability state,
specifically for this purpose.
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/