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 X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 526E7C4363D for ; Thu, 24 Sep 2020 22:07:22 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C63E1208E4 for ; Thu, 24 Sep 2020 22:07:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ejvl3e1w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C63E1208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oGJNd9GY0OywgkIjesu8Z0yylyHUI5kpLfmKlb8UnCQ=; b=ejvl3e1w6gpQ7AxN8RzMAbAwU LELFoCrFcxHmvQhffPoGSpmYvIuF3FhXQ6OOKUCrL2Jdn58v9XQbSGYL3i/jV9s0Og1AnIlgOH9Cu Dq+7wOEqgN8sYoJ2w682aia4o37xeK2ixC6ZtN8Hl6QXl4G7T4AduMekhr0yJzeHl7ZahNFjoBZxQ I0LIciQ58XPCD83m3l22aswZPsPKdzP6IAPcysL6I08fSbpLUJ3ya8E8+XOtraiMYlN4XceRmNkH8 xfCbyFp8X4JMmUY1J0RSaAtFfNEDihr9rQzSsto12OQE1KQyG1bRjaW4mJxO7KDaY9WK6Qp/hw1WN PKwznm1Wg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLZN9-0007qd-1H; Thu, 24 Sep 2020 22:05:51 +0000 Received: from jabberwock.ucw.cz ([46.255.230.98]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLZN5-0007po-EN for linux-arm-kernel@lists.infradead.org; Thu, 24 Sep 2020 22:05:49 +0000 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 251041C0BD9; Fri, 25 Sep 2020 00:05:42 +0200 (CEST) Date: Fri, 25 Sep 2020 00:05:40 +0200 From: Pavel Machek To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Message-ID: <20200924220540.GA13185@amd> References: <210d7cd762d5307c2aa1676705b392bd445f1baa> <20200922215326.4603-1-madvenka@linux.microsoft.com> <20200923084232.GB30279@amd> <34257bc9-173d-8ef9-0c97-fb6bd0f69ecb@linux.microsoft.com> <20200923205156.GA12034@duo.ucw.cz> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200924_180547_593365_C006AC4D X-CRM114-Status: GOOD ( 25.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fweimer@redhat.com, mark.rutland@arm.com, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, "Madhavan T. Venkataraman" , linux-security-module@vger.kernel.org, David.Laight@ACULAB.COM, luto@kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============2425669536039013450==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2425669536039013450== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >>> I believe you should simply delete confusing "introduction" and > >>> provide details of super-secure system where your patches would be > >>> useful, instead. > >> > >> This RFC talks about converting dynamic code (which cannot be authenti= cated) > >> to static code that can be authenticated using signature verification.= That > >> is the scope of this RFC. > >> > >> If I have not been clear before, by dynamic code, I mean machine code = that is > >> dynamic in nature. Scripts are beyond the scope of this RFC. > >> > >> Also, malware compiled from sources is not dynamic code. That is ortho= gonal > >> to this RFC. If such malware has a valid signature that the kernel per= mits its > >> execution, we have a systemic problem. > >> > >> I am not saying that script authentication or compiled malware are not= problems. > >> I am just saying that this RFC is not trying to solve all of the secur= ity problems. > >> It is trying to define one way to convert dynamic code to static code = to address > >> one class of problems. > >=20 > > Well, you don't have to solve all problems at once. > >=20 > > But solutions have to exist, and AFAIK in this case they don't. You > > are armoring doors, but ignoring open windows. >=20 > FYI, script execution is being addressed (for the kernel part) by this > patch series: > https://lore.kernel.org/lkml/20200924153228.387737-1-mic@digikod.net/ Ok. > > Or very probably you are thinking about something different than > > normal desktop distros (Debian 10). Because on my systems, I have > > python, gdb and gcc... >=20 > It doesn't make sense for a tailored security system to leave all these > tools available to an attacker. And it also does not make sense to use "trampoline file descriptor" on generic system... while W^X should make sense there. > > It would be nice to specify what other pieces need to be present for > > this to make sense -- because it makes no sense on Debian 10. >=20 > Not all kernel features make sense for a generic/undefined usage, > especially specific security mechanisms (e.g. SELinux, Smack, Tomoyo, > SafeSetID, LoadPin, IMA, IPE, secure/trusted boot, lockdown, etc.), but > they can still be definitely useful. Yep... so... I'd expect something like... "so you have single-purpose system with all script interpreters removed, IMA hashing all the files to make sure they are not modified, and W^X enabled. Attacker can still execute code after buffer overflow by .... and trapoline file descriptor addrsses that"... so that people running generic systems can stop reading after first sentence. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --SUOF0GtieIMvvwua Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl9tGDQACgkQMOfwapXb+vJJrACguUwBUXADnMj7K1we9pMBCXao yuMAoLYUAsqVN8r3PK8Ax9IBA9TWFYbf =yH8g -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- --===============2425669536039013450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============2425669536039013450==--