Re: [RFC] Expose request_module via syscall

["Thomas Weißschuh" <thomas@t-8ch.de>]

On 2021-09-15T18:02+0200, Greg KH wrote:
> On Wed, Sep 15, 2021 at 05:49:34PM +0200, Thomas Weißschuh wrote:
> > Hi,
> > 
> > I would like to propose a new syscall that exposes the functionality of
> > request_module() to userspace.
> > 
> > Propsed signature: request_module(char *module_name, char **args, int flags);
> > Where args and flags have to be NULL and 0 for the time being.
> > 
> > Rationale:
> > 
> > We are using nested, privileged containers which are loading kernel modules.
> > Currently we have to always pass around the contents of /lib/modules from the
> > root namespace which contains the modules.
> > (Also the containers need to have userspace components for moduleloading
> > installed)
> > 
> > The syscall would remove the need for this bookkeeping work.
> 
> So you want any container to have the ability to "bust through" the
> containers and load a module from the "root" of the system?

Only those with CAP_SYS_MODULE.
Having this capability would also allow them load the module normally when
mounted in or potentially downloaded from the internet.

> That feels dangerous, why not just allow a mount of /lib/modules into
> the containers that you want to be able to load a module?

This is what we are currently doing. But sometimes this gets forgotten at some
point in the chain of nested containers/namespaces and things break.

> Why are modules somehow "special" here, they are just a resource that
> has to be allowed (or not) to be accessed by a container like anything
> else on a filesystem.

They are special insofar as they always have to match the running kernel.
Which is managed by the root namespace.

The biggest problems would probably arise if the root namespace has non-standard
modules available which the container would normally not have access to.

I think this is a big potential problem and which would not be justified by the
quality of life improvement.

Sorry for the noise.

Thomas