From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id SLRnKAYyAWOaOAAAbAwnHQ (envelope-from ) for ; Sat, 20 Aug 2022 21:12:06 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 4ABlKAYyAWPAQQAAauVa8A (envelope-from ) for ; Sat, 20 Aug 2022 21:12:06 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7EE87F1D1 for ; Sat, 20 Aug 2022 21:12:06 +0200 (CEST) Received: from localhost ([::1]:47172 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oPTt7-0000bl-Ly for larch@yhetil.org; Sat, 20 Aug 2022 15:12:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPTsf-0000bW-Oi for guix-devel@gnu.org; Sat, 20 Aug 2022 15:11:37 -0400 Received: from knopi.disroot.org ([178.21.23.139]:50426) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPTsd-0007k8-IF for guix-devel@gnu.org; Sat, 20 Aug 2022 15:11:37 -0400 Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 0002D4005B; Sat, 20 Aug 2022 21:11:30 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXvqoyXtnQoB; Sat, 20 Aug 2022 21:11:29 +0200 (CEST) Date: Sat, 20 Aug 2022 19:11:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1661022689; bh=pXyiHsMwvcAf49KR+sHmFky5tvKH4COVstd09TVPARo=; h=Date:From:To:Subject:In-Reply-To:References; b=HtRD4IxXDg/SaRxBvd6DzPLkJkeRS8o68rH9FiVveBD2+roNwHEYUqVwkcmTlcY15 J+PnJSKBpO6Z6QxNZD5XmtqqFceK1IyztrS1Z+l5bPLlgqzFTT2+N4sQF/xcghhodB 2duc1A4EnjXxMWrvBPaDRsMlGyKlNg5ChFvDADbnzLNB2IgBMtOLNaFWR1Tu9/156a fBpjpitZ3WhTsK4kooQ8mSPdpkg9W9vYwhZZOXcbB9bTgr+mvd3yw+gAtbnUz5gt04 dh6M/unzNcCTwKbS5Hlf9yjvNyrcUvMYvgxs3hg9qBv7b0q8XGNlOOT6mHOi23jGqJ LeJKg5Nc7ZH+w== From: kiasoc5 To: guix-devel@gnu.org, Subject: Re: secure boot Message-ID: <20220820191125.53fb6d03@aria> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=178.21.23.139; envelope-from=kiasoc5@disroot.org; helo=knopi.disroot.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1661022726; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=pXyiHsMwvcAf49KR+sHmFky5tvKH4COVstd09TVPARo=; b=sDKRcwplnbGAEdCpozsXxrqrX2IxJNfoA376LcWRihDQj91jg2q/WH/JABUs/GeD3yAl25 y4PRWncxtM8J8eGxf4jIFhvK45na+rBmovdOpHL169BMf61hxLKNKMIr7nfow6PYU8QnRd Ainb1B8QyW4PbpHaIyWe9v1lGioBFV8TDDde1ANX8mjVdoewMoTDIW22b2E8cuLXjwbsLU QGKZ1UDGxl0lTGeobM1iuX4IHe0lPVDZbrT2aDz5pq+CO6IUzsrzETPglrpGoKMtgXaFkT YvncnBbPfMwObS0AdlCqvVH4sX+9c30UTgE9dWHzVQZ3aKwA3e4b/wVjXVUmFA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1661022726; a=rsa-sha256; cv=none; b=UqyhRoIF4NtT+NZMk5h8gzcrnuQCqIUz4kPIE202xVFalMFmq9brEKaggt0XkU7+SGcE5j K0Q89MhFg7G3XC7K2jJIxXBKS5MYc5pI7AArnFzcEFfeA5wFYtZ/3t1yvPphwDgk7RJe3z RC8TY3yYMC5voCGnm74TQiolZZxDDQl1ZbtzfxrKHqhCc+3mVB3idOMrbqDnk/qoq7giZs gutKT6kfNOZ/OF32qv2fJ8yc92/kU/0qb6oViSubJmAajLXpLE3yb7P0gZMhBEm1U0vvjZ LxNL/G/W2fQlrinCYK75ilt2h5E9COKaVOij6HZbvAVVEk90VS/lUn6DeyGYXA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=disroot.org header.s=mail header.b=HtRD4IxX; dmarc=pass (policy=quarantine) header.from=disroot.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.15 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=disroot.org header.s=mail header.b=HtRD4IxX; dmarc=pass (policy=quarantine) header.from=disroot.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 7EE87F1D1 X-Spam-Score: -4.15 X-Migadu-Scanner: scn0.migadu.com X-TUID: Ov0LrWr+vHjP Hi Antonio, On Sat, 2022-08-20 at 13:23 +0200, Antonio Carlos Padoan Junior wrote: > As far as I understand, Guix doesn't provide means to automatically > sign > bootloaders and kernels in order to use UEFI secure boot after each > system > reconfigure (assuming a PKI is properly implemented).=C2=A0 Hence, using > secure boot with Guix is currently not viable (am i correct?). Guix has sbsigntools packaged so you may sign Grub itself after each system reconfigure. But signing only Grub is not enough, because Grub does not yet validate the secure boot signatures of the kernel and initramfs. So we currently do not have 100% secure boot. We should make sure all files used in the boot process are signed. This includes, the bootloader itself, the configuration file, the kernel binary, and the initramfs [1]. One way to do this is to boot an signed efistub containing all of the files that need to be verified. You could boot efistub directly via UEFI, use systemd-boot/gummiboot, or have Grub chainload an EFI. Guix doesn't support gummiboot/EFI chainloading yet, so efistub through UEFI seems the easiest. You would create an efistub, add it to efi partition, sign it, and add it to UEFI with efibootmgr with each system reconfigure. This removes the need for GRUB since each efistub would boot the correct system generation, although the efi partition would need to be cleaned occasionally since efistubs do take up disk space. Another way is to sign the bootloader with secure boot keys, and then sign the initramfs, kernel, and config with GPG keys [2]. This seems easier to achieve with current Guix tooling. Automating these processes might be tricky because we have to avoid putting keys for secure boot in the store since it's world-readable. For reference NixOS has not officially implemented secure boot either. Their current progress afaik is they are working on bootspec, "a set of memoized facts about a system's closure." This would enable them to support secure boot more easily later [3,4]. > In this context, can I assume that the risk of not having secure boot > is > minimized by the fact that in each system reconfiguration, the early > boot chain is overwritten is such a way that, if a malicious is > introduced somehow, it will be also overwritten? Am I correct? Secure boot concerns the evil maid attack, which affects the bootloader and efi system partition. I'm not sure which parts of the boot chain are overwritten during system reconfigure, but in any case you must boot the system to reconfigure. If you don't have secure boot, then you have no protection against loading maliciously implanted boot executables. > In addition, how much more difficult it is to introduce such > malicious > code in a Guix system giving its functional approach and store > system? > (in comparison with others Linux distributions). Assuming one doesn't have root, they could modify code inside any .scm files you are using (system generation, profiles, etc) to put files in the store next time you run a Guix command that modifies the store. Of course, they have to get into your system first. This is the only attack I could think of. > I know that Guix provides an amazing approach to secure software > supply > chain, but I as wondering if not having secure boot can be considered > a major drawback for Guix. If evil maid is in your threat model then I would not run an OS that does not have secure boot. You can still run Guix package manager on a Linux that does support secure boot (eg Parabola). That being said many great OSes such as the BSDs do not support secure boot so I don't think it's a major drawback. 1. https://git.alpinelinux.org/aports/tree/main/gummiboot/APKBUILD 2. https://libreboot.org/docs/gnulinux/grub_hardening.html 3. https://github.com/NixOS/rfcs/pull/125 4. https://github.com/grahamc/rfcs/blob/bootspec/rfcs/0125-bootspec.md