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 00066C4332F for ; Sat, 3 Dec 2022 08:51:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230151AbiLCIvZ (ORCPT ); Sat, 3 Dec 2022 03:51:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbiLCIvZ (ORCPT ); Sat, 3 Dec 2022 03:51:25 -0500 X-Greylist: delayed 132124 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sat, 03 Dec 2022 00:51:24 PST Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FD011171 for ; Sat, 3 Dec 2022 00:51:24 -0800 (PST) Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4NPNnx4HD6z9sQL; Sat, 3 Dec 2022 09:51:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1670057477; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cveCfaQdqG1vHDIGKoiHSh0Rw6hx4sOM3mA9zIYHxdo=; b=NGDv8yUfd0KqWoh+aA4BEna8ZOyFkrNadZ0TuW+5XpvT7mvGQYTIv6ulzPEzN8wdZRrk5s m27DzI1mkwUrzZnD4Gty2DX7eHlKSzYtfeZJv5aDSUmOSNVET176foo4L8Zo+qR8t6dSuJ fmu3phcCaZNr8q9MUmGRewy8N262e1llwX0bGBpiPzieknUhlUarx10xWE0kECBUMRdZdW xBGJhzMSaEPc+PuXcEPZBOZR82gljOvIN0cjsGk/+2k2z26BXqAF+WqhaieyFGiR5DJZlH l11Vj4uItS1GWlt2Pq7yWmIjdODvAfg/f2iS7Y/N3wbHeBsbHo6Dt9f9svOL7g== Date: Sat, 3 Dec 2022 09:51:12 +0100 From: Stefan Bavendiek To: kernel-hardening@lists.openwall.com Cc: linux-hardening@vger.kernel.org Subject: Re: Reducing runtime complexity Message-ID: References: <202212011520.F7FE481@keescook> <202212021208.04CE21D1AE@keescook> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GKWtZWeVdIpczgEH" Content-Disposition: inline In-Reply-To: <202212021208.04CE21D1AE@keescook> X-MBO-RS-META: 6ep5am96nkm35818b5mqnjxwy95s3wkh X-MBO-RS-ID: 129047620a5f10884ed Precedence: bulk List-ID: X-Mailing-List: linux-hardening@vger.kernel.org --GKWtZWeVdIpczgEH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2022 at 12:13:48PM -0800, Kees Cook wrote: > On Fri, Dec 02, 2022 at 07:31:06AM +0100, Stefan Bavendiek wrote: > > On Thu, Dec 01, 2022 at 03:21:37PM -0800, Kees Cook wrote: > > > On Thu, Dec 01, 2022 at 09:09:04PM +0100, Stefan Bavendiek wrote: > > > > Some time ago I wrote a thesis about complexity in the Linux kernel= and how to reduce it in order to limit the attack surface[1]. > > > > While the results are unlikely to bring news to the audience here, = it did indicate some possible ways to avoid exposing optional kernel featur= es when they are not needed. > > > > The basic idea would be to either build or configure parts of the k= ernel after or during the installation on a specific host. > > > >=20 > > > > Distributions are commonly shipping the kernel as one large binary = that includes support for nearly every hardware driver and optional feature= , but the end user will normally use very little of this. > > > > In comparison, a custom kernel build for a particular device and us= e case, would be significantly smaller. While the reduced complexity won't = be directly linked with reduction in attack surface, from my understanding = the difference would make a relevant impact. > > > >=20 > > > > The question I keep wondering about is how feasible this is for gen= eral purpose distributions to have the kernel "rebuild" in this way when it= is installed on a particular machine. > > >=20 > > > Much of the functionality is modules, so once a system is booted and > > > running the expected workloads, one can set the modules_disabled sysc= tl > > > and block everything else from being loaded. > > >=20 > > > -Kees > > >=20 > > > --=20 > > > Kees Cook > >=20 > > Disableing modules in general will prevent quite a lot of functionality= that would still be expected to work, like plugging in a usb device. > > One approach may be to load everything that may possibly be required in= the future as well based on the use case of the specific system and then d= isable loading additional modules, but that does not seem like a good solut= ion either. > >=20 > > Perhaps exploring embedded device deployments is an idea, but in genera= l the idea is to ship a smaller kernel to something like Linux desktops wit= hout limiting functionality that likely to be required. >=20 > What I mean is that we already have a good middle-ground. It doesn't > need to be all (general distro) or nothing (embedded build). Once the > workload for the system is known, load the needed modules and block > everything else. i.e. set up a module alias named "disable", and then > fill /etc/modules with whatever you might want that isn't automatically > loaded at boot and end the list with "disable". I wrote this up almost > exactly 10 years ago: >=20 > https://outflux.net/blog/archives/2012/11/28/clean-module-disabling/ >=20 > :) >=20 > -Kees >=20 > --=20 > Kees Cook This does look quite similar to what I had in mind. Thank you for the response. - Stefan --GKWtZWeVdIpczgEH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEjLwAv8xLYF1doyZLdIuckz2DLQMFAmOLDfQACgkQdIuckz2D LQN++Q//dvAhf+uwS0SA3mlylDAADGymjtWVSioO00FTWQ8OeAhhgA+2uhk0QzD+ d61jvt3gNLfdW/D5pesukit+9sId8zl51Q8MqOlQgmmWHXEA5rLDS8NsKSldX7UL A8iJ4sutT3AEIm2LFX1jUGZ/g60rqKL3g3P2TyXXVayiIgtWUCE79LCdZXEJReqV 2i8i3LkMZgRzsHqvQHkQNY84wJc6hHLfmX065gW/1k2XRuyc5Xjh4s5/VfoI/Gc8 2tMDxATHQOD9k4R2ST/6QRn3BQryWEa2sXxwXkws+DvUKwJwVnvUqToocMP0H1Ex 75s+dTXGO8L40D4YcFDlQ+wBQGMBhUpd4rDY6jB4hAzPsLmYxnhFgzjgB6EBnb2Q 8BgGIq9rgxFtFOmWlrfKb/PrPqVs08CevI1tYPlfse636McahMBQLM1S6QwBvDcg BTCSMoLMb3xC3eixPzjd8bGyZKr1qD19s51uU10d0ASa/jw4DZMj3ljhp83Ts5nF ZvTu63oyJuNlLBPSAnoPyS3tkfNMDHrdRkv2HweDSQXNjXmi8v3ALSnbw7yk9AFX ec4xabRCplEQF/qgtpKxZg216WJTgmhvOfjwFdiB+TaMQGxjyE75AZ75YqUeBvPI TwvA6AGnZfBu1tW181nqDJ4YPKg/bZcF0wrkIYZSRK5oOFcqWuc= =VOkn -----END PGP SIGNATURE----- --GKWtZWeVdIpczgEH--