Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp497628imm; Fri, 17 Aug 2018 01:26:56 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzWyVqexAqtXsiCKcdIT/CA4OLfvZtG+J49JEkPYNpRyzaYBJkOjNiC7wNI5Dkj1f7W7pxt X-Received: by 2002:a17:902:b08d:: with SMTP id p13-v6mr33329088plr.0.1534494416724; Fri, 17 Aug 2018 01:26:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534494416; cv=none; d=google.com; s=arc-20160816; b=YixBwxFmMOANBJWifNkj6KbUL0c9av+FMBakoC+MO4T/KM4BHCVcpLbzvZV/DTyXNy 8YMW3A3/74iFV3gyun4pMGUPYUUKAYjrvMswgk1HTiWMs6U/oslQKnPCl+LS1AiucMZS S/k0vGkN0IDFtlXMIfXHDqpAuT/9+cSzzNIWUHEzIFnMxYyFohj5UwQcH+gUomaWzc+w 51rx5C6tFb855VEB9Bux/mWPJksM9ic59+R7R1XPJB3sxTjnGXEOmEvrAdY4442f46p/ H8ySiTXRlNO2cEuu0fFrpiOupux/j4xHLoHjoDV3CQP3mEu50u5X75v5uU0KCXUd8b5g qRTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:content-transfer-encoding :mime-version:subject:cc:to:references:in-reply-to:from:organization :arc-authentication-results; bh=RGL2lE4u+tzOE/WfgbsmARRmnIe1Tss7FQMUIiWmN80=; b=dzIP/Ol5LXrxJxcarygWztgULya5/ZwGXKbFbnkRSZLUFRsaZCqP0KXsB0vxMjZDnW /JCl+JPzZDMUh60NH7KC9v6V14S+CGjRazVt1kzkzMWWBIVo89IAneTHQ+4AzxAvMlFb /5U6y/8Rq0Vaj06CphT1s89L4k3bLiCEhpggs9fTHHO5ZSruR536Pm/KGjaFF/hxxBgL 6ZPJeQROqQyLjLgaQOncMa1/Y/117lrJiL35RNJlQWz6bKB0dPHocYLkOl/oGVTUXXye Lmt9rQKTMSvnBRRN0ZkecMTWk9UAPQ/XCBOs+/eIFz9dUWokkXjTAMfw5DIObVxFh/es NU3g== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s11-v6si1717908pfc.340.2018.08.17.01.26.41; Fri, 17 Aug 2018 01:26:56 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726784AbeHQL10 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 17 Aug 2018 07:27:26 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39832 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726349AbeHQL10 (ORCPT ); Fri, 17 Aug 2018 07:27:26 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 18265406E885; Fri, 17 Aug 2018 08:24:58 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-120-130.rdu2.redhat.com [10.10.120.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id A527810D18CA; Fri, 17 Aug 2018 08:24:53 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1534464451.22442.1.camel@HansenPartnership.com> References: <1534464451.22442.1.camel@HansenPartnership.com> <1534435000.3166.9.camel@HansenPartnership.com> <1534432615.3166.5.camel@HansenPartnership.com> <20180815100053.13609-1-yannik@sembritzki.me> <654fbafb-69da-cd9a-b176-7b03401e71c5@sembritzki.me> <20180815174247.GB29541@redhat.com> <20180815185812.GC29541@redhat.com> <20180815194932.GD29541@redhat.com> <20628.1534427487@warthog.procyon.org.uk> <30607.1534434597@warthog.procyon.org.uk> <18926.1534451480@warthog.procyon.org.uk> To: James Bottomley Cc: dhowells@redhat.com, Linus Torvalds , Vivek Goyal , yannik@sembritzki.me, Thomas Gleixner , Ingo Molnar , Peter Anvin , the arch/x86 maintainers , Linux Kernel Mailing List , Dave Young , Baoquan He , Justin Forbes , Peter Jones , Matthew Garrett Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Date: Fri, 17 Aug 2018 09:24:53 +0100 Message-ID: <28088.1534494293@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 17 Aug 2018 08:24:58 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 17 Aug 2018 08:24:58 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dhowells@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James Bottomley wrote: > > > As a step by step process, I agree.  However, I think we can > > > automate it to the point where you install a package and it says > > > "insert your yubikey" every time you upgrade the kernel > > > > That's a very bad idea.  You train people to unlock their private key > > on request.  It can be abused like one of those emails that tells you > > that your account has been suspended - just follow the link and put > > in your password please. > > It's exactly the same process those of us who use yubikeys for gpg or > ssh keys follow. You insert your key, you activate the process that > needs the key, it asks for you to confirm your key, you press the > button and the operation gets performed. Since it's what we as kernel > developers do, I don't see why it's a bad idea for others. You've completely missed the point. You need to think from the PoV of an ordinary user. Imagine the system does an automatic upgrade and wants to upgrade the kernel. It pops up a dialogue box saying "please put in your yubikey and enter your password here"[**]. It might do this on a regular basis - and you can be sure that some users at least will become accustomed to just doing this when their computer tells them too. *That* is the problem. Now they follow a link to a dodgy website that causes some code to be downloaded and run. *It* now pops up a dialogue box that looks exactly like the kernel installer's dialogue that says "please put in your yubikey and enter your password here". But now we've trained those users to do this on demand... PEBKAC[*]. [*] Note that I'm not trying to slight ordinary users here, it's more a fact of psychology. As a distribution, it's our responsibility to try and protect them as best we can - and training them to unthinkingly bypass the security mechanisms isn't in anyone's best interests. [**] Note also that I've never actually used a yubikey[***], so I'm not sure whether it takes a password or has some other mechanism to unlock the key. [***] We also don't want to require that someone buys and keeps track of a yubikey to be able to use, say, the NVidia driver with Fedora/RHEL. Using the TPM if installed would be preferable because it's harder to lose. We also don't necessarily want to encourage ordinary users to fiddle with the system key databases unless they really know what they are doing. There've been cases where doing this has bricked a machine because the BIOS is buggy. Now I will grant, since you'll probably raise it if I don't;-), that this might be a good reason *for* having our own third party signing key as we could then build the key into our kernels. But if they use a yubikey, they have to get the public key from there into the system key list or possibly the yubikey has to be accessed by the bootloader. The same for the TPM. > > Further, you expose the unlocked key on a machine that might be > > compromised. > > No it doesn't; the point about using a yubikey (or any other HSM type > thing) is that the key is shielded inside the module so you get a > signature back and the key can't be compromised even if the machine is. Yes, you do. Note that I don't mean necessarily exposing the actual key material, but you do have to make it available for use - which means someone can then use it and there's a window in which it is available for that use. If there wasn't, it would be useless. > > No, you can't.  You might *think* that it is, but the signature > > you're checking is after the image has being fiddled with by the key- > > adder > > Well, yes, you have to add a new signature to the combination. > However, you can always verify that the hash without the added key is > the hash of the Red Hat supplied bzImage. At what point would you do this? You have to assume that your userspace tools can be compromised unless they are also verified (signature/IMA). No, this needs to be done by the bootloader. Sometimes I feel I've spent too much time talking to people about security and their paranoia is rubbing off... ;-) David