linux-kernel - Re: [RFC] Expose 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]

Date:   Wed, 15 Sep 2021 18:28:27 +0200
From:   Thomas Weißschuh <thomas@...ch.de>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
        Luis Chamberlain <mcgrof@...nel.org>,
        Jessica Yu <jeyu@...nel.org>
Subject: Re: [RFC] Expose request_module via syscall

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