Received: by 10.223.185.116 with SMTP id b49csp664573wrg; Wed, 14 Feb 2018 05:11:39 -0800 (PST) X-Google-Smtp-Source: AH8x226VkgOOMbaBjRuSqoFQEOOgK1bxsI+2iGmGKkGkQcA+9nsndxJaaiG3nmjVXZ4fwzlWufHk X-Received: by 2002:a17:902:7887:: with SMTP id q7-v6mr4455736pll.385.1518613899035; Wed, 14 Feb 2018 05:11:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518613898; cv=none; d=google.com; s=arc-20160816; b=lZJShBRUYuPzIKVAHZr8GIgCj/AwYfpPIpLml/8HjbKBsYJYxHjcdXVK58topWBmTT rlTeB7kUCuezmALE0mhHGpBI+/wlFu7LFH2t27HEz9dYbyESir12AvPh3Xr7jFSqlke1 jFeVtwNs7cL7RVyrS49HfOE1xGFZQHNPAm8zrPMVfvWUxfCxHG7zO5JsMnW3IqJbL/no S8oDqg/+RiWFRJEjRUdYYta6MTmm12u7yIuIHrlhGbB80LGpebRtc6/8J9pVtW8DE3B2 peDi5qkSruQp2dB0a8Xr0KPo2LDlI+L5LT9mGUetSwSEWo8rRmu73o9z+mur+8yPfEan 7DCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=n6rOltVZlMC9u0HbUrp0yFAbp9eC2BS+duuS4gtdddM=; b=Hb955io0i9B99Wf3JVHXEEanhJoAk8gw94QqeLf/6SabTdtqi6JlrarK37flDkfMUK bJkWE+CDr+srx9uJzNpyqTjIAsWHnV0HQ8ZtmX99YlKHEE3NEjWF2czjg45wnWDy51Xm KGlT5yzyb2mMujxN+XSY+Ah5GWmLTdtuuBt2sFpKvKftnDq9lhf4c9o0BOR63ZLXNBKH 7cQHYOIJXwNuYyde0Y/XcqkZO27kb5xkQ5/fZNvrb1fHDUklWK0xfQ24dzyWgnbN7VsG 344CMPuvn2V7NkhiFuDobrHGytfZFlvZjydiRjWF2eJUATF2fJ6Dj3vIlfPf3E9UD7lt a+CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jHr6bSFy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 43-v6si2920312pla.70.2018.02.14.05.11.22; Wed, 14 Feb 2018 05:11:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jHr6bSFy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967821AbeBNNKB (ORCPT + 99 others); Wed, 14 Feb 2018 08:10:01 -0500 Received: from mail-it0-f48.google.com ([209.85.214.48]:36498 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967706AbeBNNKA (ORCPT ); Wed, 14 Feb 2018 08:10:00 -0500 Received: by mail-it0-f48.google.com with SMTP id n206so14923537itg.1 for ; Wed, 14 Feb 2018 05:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n6rOltVZlMC9u0HbUrp0yFAbp9eC2BS+duuS4gtdddM=; b=jHr6bSFy+20fGc67fH8dsAj/hA6TPM+FdhcMJ/N/5n9OCFMmyuL1Y/aVuTfSP/HdLI rCvXFrONTHtX+PdORuE7a+TKfeuQTYshcijFi39mCUL3YlwPifvNawMt5X02cASpn6Su /7VY3iLVM8nOT13UE2wQpinyCOHlfoFEeXhIw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n6rOltVZlMC9u0HbUrp0yFAbp9eC2BS+duuS4gtdddM=; b=aqs+b1UMTx0JXo1Q82w5gCdwQRcY8gjg8sgqaWf9Ljc8eB6L+Z7d1OFMWjnuC//n2l xAm9BJlI1y+A9WYiSEsAmuuCpYyliSE9rw3o5RGR8FV9lJ/5hBRGTa6vwrGzeB7Zfqgm 1fBybC6bZEZEmXA1nrSDgwHR44yJSNeSV6TWwQOhPtYvbkyT9Nsu1dj7G6HJ2u8ntjJl iIUt2+jCirCNu7X+7K6AWH/cxrSsXGwa2TzH/5NlvF17pK/yNVzpcorfE4ye9EjJd3mS MGXvBFbSyRnhChFOx84BZtrTGCiq+WLW4RLwX5ah+K3g2xjqr/CsD78DUMqSOnv3DjtF 6HKg== X-Gm-Message-State: APf1xPBoSAKoASQkhUYqbOSpu2GYEG6K1Kna2Dqc3pbjV9Jk+ZS8NCi/ hmT3LtRYVLvfzsRtVyRxqsc5ZGxHCpudwJWTIeyR6Q== X-Received: by 10.36.237.204 with SMTP id r195mr3077326ith.59.1518613799660; Wed, 14 Feb 2018 05:09:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.112.13 with HTTP; Wed, 14 Feb 2018 05:09:59 -0800 (PST) In-Reply-To: <1518612748.4749.29.camel@profitbricks.com> References: <1518612748.4749.29.camel@profitbricks.com> From: Ard Biesheuvel Date: Wed, 14 Feb 2018 13:09:59 +0000 Message-ID: Subject: Re: Read-protected UEFI variables To: Benjamin Drung Cc: Matthew Garrett , Jeremy Kerr , Matt Fleming , linux-efi@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14 February 2018 at 12:52, Benjamin Drung wrote: > Hi, > > I am exploring the possibility to store SSH and other keys in UEFI > variables for systems that do not have persistent storage. These > systems boot via network and need individual SSH keys which ideally > should not be distributed via network. > > The plan is to write a small daemon that starts at boot and gets the > SSH keys from EFI variables to individualize the system with SSH keys. > I plan to release the code as free software. Simple proof-of-concept > code: > > mount -t efivarfs none /sys/firmware/efi/efivars > for key in ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_rsa_key; do > dd ibs=1 skip=4 if=/sys/firmware/efi/efivars/${key}-89df11f4-38e6-473e-ab43-b4406b76fba9 of=/etc/ssh/$key > done > > I am not the first person having the idea to use UEFI variables to > store keys: > https://www.usenix.org/conference/srecon17asia/program/presentation/korgachin > > There is one problem: The keys should be readable only by root. When > mounting efivarfs, all variables have the permission 644 which makes > them readable by all users. I have different ideas how to solve it: > > 1) Hard-code a list of GUIDs that should be only readable by root in > the kernel module. These modules would also be not set to immutable. > > 2) Instead of hard-coding GUIDs, add a kernel module parameter to > specify the GUIDs. Maybe have a default list in the kernel module. > > 3) Add a mount option to specify the protected GUIDs. > > Feedback is welcome. > I'd consider a patch that makes the permissions a mount option for efivarfs, applying to all variables. The reason is that these variables shouldn't have been world readable in the first place, and I am reluctant to make this overly complex. On the other hand, you should realize that UEFI was never designed to keep secrets, and so whether it is a good idea to put secrets in UEFI variables to begin with is dubious IMHO.