Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1302-gc62ab821ef-fm-20210921.001-gc62ab821
Mime-Version: 1.0
Message-Id: <59e230b3-0e85-42ff-84a8-6b30ad0719d8@www.fastmail.com>
In-Reply-To: <20210922122523.72ypzg4pm2x6nkod@wittgenstein>
References: <705fde50-37a6-49ed-b9c2-c9107cd88189@t-8ch.de>
 <CALCETrUM0cko=5ki-Dd402DNFU2TmgnJTz_vfrsaofkGD-1kmA@mail.gmail.com>
 <20210916092719.v4pkhhugdiq7ytcp@wittgenstein>
 <2ebf1a9d-77d5-472b-a99a-b141654725da@www.fastmail.com>
 <6eff0e8a-4965-437d-9273-1d9d73892e1a@t-8ch.de>
 <CALCETrWA1TBvbknH1Jzt=newTd4sHzNFm0RPuRxazjuRQRsR7w@mail.gmail.com>
 <8cbf0703-5734-4e92-a6cc-12de69094f95@t-8ch.de>
 <YUi95tFDWS7oceYP@bombadil.infradead.org>
 <CALCETrX9keVFxEZYUkKr7_dWb9Ubo9q4E2aTY_ZOWGSHyRph8g@mail.gmail.com>
 <20210922122523.72ypzg4pm2x6nkod@wittgenstein>
Date:   Wed, 22 Sep 2021 08:34:23 -0700
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Christian Brauner" <christian.brauner@ubuntu.com>
Cc:     "Luis Chamberlain" <mcgrof@kernel.org>,
        =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <thomas@t-8ch.de>,
        "Linux API" <linux-api@vger.kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        "Jessica Yu" <jeyu@kernel.org>
Subject: Re: [RFC] Expose request_module via syscall
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Sep 22, 2021, at 5:25 AM, Christian Brauner wrote:
> On Mon, Sep 20, 2021 at 11:36:47AM -0700, Andy Lutomirski wrote:
>> On Mon, Sep 20, 2021 at 11:16 AM Luis Chamberlain <mcgrof@kernel.org>=
 wrote:
>> >
>> > On Mon, Sep 20, 2021 at 04:51:19PM +0200, Thomas Wei=C3=9Fschuh wro=
te:
>>=20
>> > > > Do you mean it literally invokes /sbin/modprobe?  If so, hookin=
g this
>> > > > at /sbin/modprobe and calling out to the container manager seem=
s like
>> > > > a decent solution.
>> > >
>> > > Yes it does. Thanks for the idea, I'll see how this works out.
>> >
>> > Would documentation guiding you in that way have helped? If so
>> > I welcome a patch that does just that.
>>=20
>> If someone wants to make this classy, we should probably have the
>> container counterpart of a standardized paravirt interface.  There
>> should be a way for a container to, in a runtime-agnostic way, issue
>> requests to its manager, and requesting a module by (name, Linux
>> kernel version for which that name makes sense) seems like an
>> excellent use of such an interface.
>
> I always thought of this in two ways we currently do this:
>
> 1. Caller transparent container manager requests.
>    This is the seccomp notifier where we transparently handle syscalls
>    including intercepting init_module() where we parse out the module =
to
>    be loaded from the syscall args of the container and if it is
>    allow-listed load it for the container otherwise continue the sysca=
ll
>    letting it fail or failing directly through seccomp return value.

Specific problems here include aliases and dependencies.  My modules.ali=
as file, for example, has:

alias net-pf-16-proto-16-family-wireguard wireguard

If I do modprobe net-pf-16-proto-16-family-wireguard, modprobe parses so=
me files in /lib/modules/`uname -r` and issues init_module() asking for =
'wireguard'.  So hooking init_module() is at the wrong layer -- for that=
 to work, the container's /sbin/modprobe needs to already have figured o=
ut that the desired module is wireguard and have a .ko for it.

>
> 2. A process in the container explicitly calling out to the container
>    manager.
>    One example how this happens is systemd-nspawn via dbus messages
>    between systemd in the container and systemd outside the container =
to
>    e.g. allocate a new terminal in the container (kinda insecure but
>    that's another issue) or other stuff.
>
> So what was your idea: would it be like a device file that could be
> exposed to the container where it writes requestes to the container
> manager? What would be the advantage to just standardizing a socket
> protocol which is what we do for example (it doesn't do module loading
> of course as we handle that differently):

My idea is standardizing *something*.  I think it would be nice if, for =
example, distros could ship a /sbin/modprobe that would do the right thi=
ng inside any compliant container runtime as well as when running outsid=
e a container.

I suppose container managers could also bind-mount over /sbin/modprobe, =
but that's more intrusive.