From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12491C77B61 for ; Mon, 10 Apr 2023 21:26:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229761AbjDJV0B (ORCPT ); Mon, 10 Apr 2023 17:26:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbjDJV0A (ORCPT ); Mon, 10 Apr 2023 17:26:00 -0400 Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C63FD1724; Mon, 10 Apr 2023 14:25:58 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 47996320005D; Mon, 10 Apr 2023 17:25:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 10 Apr 2023 17:25:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho.pizza; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1681161955; x=1681248355; bh=cr TAf9yOGTm4ffk3dkC8Fr9jQPKpoUJV7Nw6WJRp4fI=; b=ZMWHI6FKcSv0sCDgFi uPZrQ1mKE6+TX8kfNP7LfiZnT3/NpXwJU0rxlPterjMJmKoQpmBr05aSjwjSW0Nw wZ8Nd+FwosARAgsTybYy547MeXFcpnoaK0bWMwV6pXKPDObgoSFbaN+3rcQZ3jVu bqgLDARwkwRY+lpPsLJ4hJiCBeumV9+rEOBOFnEnR1111j8qxfwurz6hl0x6C+8S gxUWCaMe4cunKcEBtuGdFpb4/BQ4nibFosDd/YmDJdzGol3ZUJbBHpSN9FcgppuC aCfSkoLD1Lgn5yHPaQdMGPJtaxSBMFZwiAfdwmiNrQYYJZcm5wyp8EjIFIqN6j1n nV5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1681161955; x=1681248355; bh=crTAf9yOGTm4f fk3dkC8Fr9jQPKpoUJV7Nw6WJRp4fI=; b=GGuMnoQcq0Yms+h3gZFnXpEAtQSmf hS8hh1TlPT22Or3+Lsz6ZeIwgXOtPBsHnPEIKKhIsStZwA6yQp9QtlFEwPCX1Mir ajopvaLPpy3R1hnH8fdVl62MO3qfIyTBYXa9iNOR8jozv0AbfBLY7DV8auBX55KQ RnLemdDzFStISulRMlPg1hizZcPm4y683TKTUbC6Mjun5BcsLF/RVWofaSfNj11P ZPgNRCYVB+jja74ymrqVP96NOQRlkotqNkDC5gUWFzTfhz6/F73mXAEk3MGMW4vN UOnVP9Ce00fD1emrHq9UZukPwxgQulpMkYVDgyqaoQKWT99AoF0uVnwGQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekvddgudeitdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefvhigt hhhoucetnhguvghrshgvnhcuoehthigthhhosehthigthhhordhpihiiiigrqeenucggtf frrghtthgvrhhnpeeutedttefgjeefffehffffkeejueevieefudelgeejuddtfeffteek lefhleelteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthigthhhosehthigthhhordhpihiiiigr X-ME-Proxy: Feedback-ID: i21f147d5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Apr 2023 17:25:54 -0400 (EDT) Date: Mon, 10 Apr 2023 15:25:53 -0600 From: Tycho Andersen To: Topi Miettinen Cc: linux-modules , Kernel Hardening , "linux-hardening@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: Per-process flag set via prctl() to deny module loading? Message-ID: References: <640c4327-0b40-f964-0b5b-c978683ac9ba@gmail.com> <4017c904-9918-3e0c-b687-f55cfc5c4f4d@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4017c904-9918-3e0c-b687-f55cfc5c4f4d@gmail.com> Precedence: bulk List-ID: On Mon, Apr 10, 2023 at 11:47:16PM +0300, Topi Miettinen wrote: > On 10.4.2023 16.36, Tycho Andersen wrote: > > On Mon, Apr 10, 2023 at 01:06:00PM +0300, Topi Miettinen wrote: > > > I'd propose to add a per-process flag to irrevocably deny any loading of > > > kernel modules for the process and its children. The flag could be set (but > > > not unset) via prctl() and for unprivileged processes, only when > > > NoNewPrivileges is also set. This would be similar to CAP_SYS_MODULE, but > > > unlike capabilities, there would be no issues with namespaces since the flag > > > isn't namespaced. > > > > > > The implementation should be very simple. > > > > > > Preferably the flag, when configured, would be set by systemd, Firejail and > > > maybe also container managers. The expectation would be that the permission > > > to load modules would be retained only by udev and where SUID needs to be > > > allowed (NoNewPrivileges unset). > > > > You can do something like this today via STATIC_USERMODEHELPER without > > the need for kernel patches. It is a bit heavyweight for a > > general-purpose system though. > > So the user mode helper would be launched whenever there is a module request > and it would check whether the process is allowed to load modules or not? Yes, exactly. > Does it know which process caused the module to be loaded and what were its > credentials at that time? It doesn't know which process caused the module load, which is kind of unfortunate. It looks like you could stick it in the environment in kernel/kmod.c:call_modprobe() without breaking too many things, though. Tycho