On Fri, 2011-02-25 at 11:43 -0800, David Miller wrote:

From: Ben Hutchings <redacted>
Date: Fri, 25 Feb 2011 19:30:16 +0000

quoted

On Fri, 2011-02-25 at 11:16 -0800, David Miller wrote:

quoted

From: Ben Hutchings <redacted>
Date: Fri, 25 Feb 2011 19:07:59 +0000

quoted

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.

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