Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1218626pxb; Thu, 16 Sep 2021 02:29:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUFJuJZhkFcW4tzkwbJkKCPntTH/eMqDWVqA0mZYPb7W5xvw0qPnyK3ZVwwNnD8bPA70T7 X-Received: by 2002:a17:907:2717:: with SMTP id w23mr5167870ejk.283.1631784558948; Thu, 16 Sep 2021 02:29:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631784558; cv=none; d=google.com; s=arc-20160816; b=p2DfxgXQD/3g9o3MbM7JE7C1tx2oOG8Q5Bx0qYYeiPT4vHzSEWG/8d6k5a85Vcmjqw GYFXTrQN67R7EXL5oLCvSp4erh46yzKI/hnJYe7oRl5btTIxcpsRtAwgoQUNnqrdS/FG xJd6t3CGjUqS0ndifxK/DZz4VK/41JkflHDn1h/Bnxser5+VmDteEZ3JLcAKewQiFa2+ 6B0O+O6DdWK6rhTmQfdc6ctSVz8JbeWjKGXTCCRcfdrZkqWpXnZ30yPWZR75Yad1wICZ MLTiH0uZqABdaMvDOWD34nsTiCKWKglEFCqGujrUX5QrfzO8Tumdpm2v9tybGRPcAUZ6 /2gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zMEUMViLhW9Lh8Z460DBo7Ig1Ccw93BEg91HPF4ZzrA=; b=L8f4QRBMq3qqlvrP2Ep+8FdOWsj4jl4jFUQvhrJ40aIRgJpqP7zUC+Ksw1C/bQvPOP kgOO0+4rGG1fQDb48/fMkM9qaBhFG0l2ffhpHJtckWEupCXp6chjybTDeqIv1VhtjV1L EVAq0yOf0SFAmLf1oui+1/blgbFyWCtD1erGJH5FZ2jVSRlcEqPKVWRH+Eajh05BjB+4 5WwDwXp6cBk5p7kod5tvnnqMLhAw4U55Ww+sRwJsUKG71FnA/TyGvfnwIswTnCaOPCLm IjPvmHe8NiuohK9l6fTFWhYv8kMnYWy80p6MKX6aQ8I1KLrLAYKgvngyZP1FJzCPj+po 9iiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c63si1994589edd.22.2021.09.16.02.28.55; Thu, 16 Sep 2021 02:29:18 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235481AbhIPJ2o (ORCPT + 99 others); Thu, 16 Sep 2021 05:28:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:48124 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235237AbhIPJ2n (ORCPT ); Thu, 16 Sep 2021 05:28:43 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BF87B60EE5; Thu, 16 Sep 2021 09:27:21 +0000 (UTC) Date: Thu, 16 Sep 2021 11:27:19 +0200 From: Christian Brauner To: Andy Lutomirski Cc: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Linux API , LKML , Luis Chamberlain , Jessica Yu Subject: Re: [RFC] Expose request_module via syscall Message-ID: <20210916092719.v4pkhhugdiq7ytcp@wittgenstein> References: <705fde50-37a6-49ed-b9c2-c9107cd88189@t-8ch.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 15, 2021 at 09:47:25AM -0700, Andy Lutomirski wrote: > On Wed, Sep 15, 2021 at 8:50 AM 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. > > I feel like I'm missing something, and I don't understand the purpose > of this syscall. Wouldn't the right solution be for the container to > have a stub module loader (maybe doable with a special /sbin/modprobe > or maybe a kernel patch would be needed, depending on the exact use > case) and have the stub call out to the container manager to request > the module? The container manager would check its security policy and > load the module or not load it as appropriate. I don't see the need for a syscall like this yet either. This should be the job of the container manager. modprobe just calls the init_module() syscall, right? If so the seccomp notifier can be used to intercept this system call for the container and verify the module against an allowlist similar to how we currently handle mount. Christian