Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1018037pxb; Sun, 19 Sep 2021 03:36:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtxKOjZqrjOy/mTuf5joP7AJf1l6AZGOYYfvaeUXqbRvWFUsLY6dRunlja56sK6p0q//N+ X-Received: by 2002:a05:6402:5206:: with SMTP id s6mr23305998edd.135.1632047760677; Sun, 19 Sep 2021 03:36:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632047760; cv=none; d=google.com; s=arc-20160816; b=kQrs4SdTwvhYNhsinn1XvA+kuURFNUvb6uVYd46U5TYOdautUYJLT5VNbpfRBzo/Ch Kem7kS7XFyFSGcdIDaDWqe3uKOSiNDXT40Y6WyNkw3jYTcqYwT0ertuDpG4+2+JRJAMF Tz9zaXCKe+i+Y0UGnKihoVs0ZcduIAOoRtg9dnBWgSTmpMdmwJ9ssWEs/D3LZfm4E6o4 bUYUvYt41xtZL0xKMCBa66MrIdAlYMyvNf8zTJmfMbbPss9NFZre6dV6jOtH4DOz8Gfe uBU+YSLasIHRE1EeedKV7KcwS0fpXexbqIA/rPoujeXkXtBeD7GHUlx1y0NhWAK1Aa/e kMBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:cc:to:from :date:references:in-reply-to:message-id:mime-version:user-agent :dkim-signature; bh=rpbl6f3NY1H1lGMpNUQKtj07WIMPnh52binqochOPIE=; b=aRS/WDkEE+BlIDzmbGiAO3SBScfE3lOSoMNc3CS4zHb8OP32kWYEVXpAk2MPseV8eL dV58iiHlr/TuU2dtwHE7RiQ2OHgsVbl/cdrGFkBoYC0Vok6U2CiBgpekzShO2PYGXFFM /4IY1o3nrofCqxt/P9bonHjlCF6I0qrz3SU/0oG9KXHgEF1+BqosTKPZD7Jhcfz50Gvx EI463GlIgN76MZkNIYfjNRDYyMSi6JYfxHGTkAzRyuwRrAMdyouW5hQ/7Zy0FYirDXks O2QnY2NYd6Eg69Em9bhf7E68WQfNmy/C+4swbJj1vw5ptsRQ6fHFavfrGmsNahFWw9zA D0dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IdW+hk+B; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw22si8217532ejc.284.2021.09.19.03.35.25; Sun, 19 Sep 2021 03:36:00 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IdW+hk+B; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233999AbhIRSs4 (ORCPT + 99 others); Sat, 18 Sep 2021 14:48:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:47548 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233539AbhIRSsy (ORCPT ); Sat, 18 Sep 2021 14:48:54 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 65F6F61179; Sat, 18 Sep 2021 18:47:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631990850; bh=sXrYWbDc0/zJ0anCv51/5CNRbVEo3f9JGglXRPxPPnA=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=IdW+hk+BdQ3c7S5r7ksVpU82/PMuLZlO9m5uoovA+dNs1ms7+dEoxBTn52xD9n2fT HURKFY2hnynlkwfIynCZgt9JVfJTTbaKCEw4++I06j4XXTJpSkn2OcKsi580V+/WEJ dT0vWJQWH+7+QEZlJjsBBsBqTcfMvHz5ejEvLtiTVm9le/XFhPlnON1INt0JM4pWbi MPWVnob20dwicujY8lQtONaoO5vPjid/ThSLbSvFwnACEScXi+ci244zUVrd1/kefF xfjIBp9YQJyu2c6z6GOaSZzbHIaUfcVr0++juekEqPMCYLRpedFQPHrdo7yGqyDEhu q3ealWrITjYQQ== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 864AD27C0054; Sat, 18 Sep 2021 14:47:29 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Sat, 18 Sep 2021 14:47:29 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehkedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpedvleehjeejvefhuddtgeegffdtjedtffegveethedvgfejieev ieeufeevuedvteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedu keehieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinh hugidrlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F2BEFA03DC4; Sat, 18 Sep 2021 14:47:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1291-gc66fc0a3a2-fm-20210913.001-gc66fc0a3 Mime-Version: 1.0 Message-Id: <2ebf1a9d-77d5-472b-a99a-b141654725da@www.fastmail.com> In-Reply-To: <20210916092719.v4pkhhugdiq7ytcp@wittgenstein> References: <705fde50-37a6-49ed-b9c2-c9107cd88189@t-8ch.de> <20210916092719.v4pkhhugdiq7ytcp@wittgenstein> Date: Sat, 18 Sep 2021 11:47:07 -0700 From: "Andy Lutomirski" To: "Christian Brauner" Cc: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , "Linux API" , "Linux Kernel Mailing List" , "Luis Chamberlain" , "Jessica Yu" Subject: Re: [RFC] Expose request_module via syscall Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 16, 2021, at 2:27 AM, Christian Brauner wrote: > On Wed, Sep 15, 2021 at 09:47:25AM -0700, Andy Lutomirski wrote: > > On Wed, Sep 15, 2021 at 8:50 AM Thomas Wei=C3=9Fschuh wrote: > > > > > > Hi, > > > > > > I would like to propose a new syscall that exposes the functionali= ty 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 kerne= l modules. > > > Currently we have to always pass around the contents of /lib/modul= es from the > > > root namespace which contains the modules. > > > (Also the containers need to have userspace components for modulel= oading > > > installed) > > > > > > The syscall would remove the need for this bookkeeping work. > >=20 > > 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 a= nd > > load the module or not load it as appropriate. >=20 > I don't see the need for a syscall like this yet either. >=20 > This should be the job of the container manager. modprobe just calls t= he > init_module() syscall, right? Not quite so simple. modprobe parses things in /lib/modules and maybe /e= tc to decide what init_module() calls to do. But I admit I=E2=80=99m a bit confused. What exactly is the container d= oing that causes the container=E2=80=99s copy of modprobe to be called? >=20 > If so the seccomp notifier can be used to intercept this system call f= or > the container and verify the module against an allowlist similar to how > we currently handle mount. >=20 > Christian >=20