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 15B17C76196 for ; Mon, 10 Apr 2023 13:36:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229664AbjDJNgZ (ORCPT ); Mon, 10 Apr 2023 09:36:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbjDJNgY (ORCPT ); Mon, 10 Apr 2023 09:36:24 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4733E4EF2; Mon, 10 Apr 2023 06:36:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 99A0A5C00E1; Mon, 10 Apr 2023 09:36:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 10 Apr 2023 09:36:20 -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=1681133780; x=1681220180; bh=Hc /zM6us12owjQAwpTXjH6fFrHxn+l06I2QCZ7puQjY=; b=ih5xW5HVZfx0inArLx gJQkJ13yTugobR+WROEywTumHayolrlDRYJKjropWd3y0tLePPVN7V3f3fX+lSal NnIdAjYw0Zg/Ggl6wewFyBgw6eUjRVs0ZvbJc8n68Pga2vkFGrW8HJWer0nYonMc /HwgYKt+uODdl1mkGyCxb/Fk8SvETH/EoN8VIhwQhwRHmLr3ZTpvYpARNIOUCdWQ F6qi0w3sY6Gl+gCzRpMpymNtR2h+8pDwzGNyhLN06BRnd3eN3FOf3+THuk4JRyMk VmP/COMlDl7e3SHa+6FWq+bt7O5SCdZLuOiRtdvNQDJQQpqlYtjQ8NPY6eaxgH+N 3vGg== 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=1681133780; x=1681220180; bh=Hc/zM6us12owj QAwpTXjH6fFrHxn+l06I2QCZ7puQjY=; b=VY3fCXC65WhFf5bteDH8gYKFF1ayu NGWJja8KgJW3dImeDFBrR7E7m5p95VnDNHXCoiU+6R+Tp5H3cWPKL105TkwoF1CY 1NaGrZB0VcDk036R9aYkysxITDncwWV9IQrVjLUo4G1JcXOYxnTpUX/onfXIC7bV 9EKqk8nErZhIkplSwqYBdW1eCeYGbDljSlXfideJglsK+rtegZyi2UImKM9nTP1v is92FYJxT6xg/JkUWv8746i7bSqrOD56ZzPaPPPtWRMN81v4HlWzMlgedeBnnK9d VWrDkXToaywBdyx6KbLVYwW4kkyh7XSrKgimrbLjnGFm9ARJZkED1bj3A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekvddgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfihtghh ohcutehnuggvrhhsvghnuceothihtghhohesthihtghhohdrphhiiiiirgeqnecuggftrf grthhtvghrnhepueettdetgfejfeffheffffekjeeuveeifeduleegjedutdefffetkeel hfelleetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epthihtghhohesthihtghhohdrphhiiiiirg X-ME-Proxy: Feedback-ID: i21f147d5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Apr 2023 09:36:18 -0400 (EDT) Date: Mon, 10 Apr 2023 07:36:16 -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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <640c4327-0b40-f964-0b5b-c978683ac9ba@gmail.com> Precedence: bulk List-ID: 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. Tycho