Received: by 10.223.148.5 with SMTP id 5csp6033008wrq; Wed, 17 Jan 2018 08:35:40 -0800 (PST) X-Google-Smtp-Source: ACJfBotHIbf+JdqQWaUVgru0MR5dCHBg6vE2yzhaBeuSVNs4dnatkigePP2kDJQXoBmqxSo02Sof X-Received: by 10.84.232.197 with SMTP id x5mr34425520plm.80.1516206939908; Wed, 17 Jan 2018 08:35:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516206939; cv=none; d=google.com; s=arc-20160816; b=NpmZoaylaVRv0i2gSZStXwvRtCaNIjz5LnEMrFJJeaMGX9hJJx8RXW3oNHEX3jAiHU 2cldwNKTVOzjWNvPvO8a/e54zBHzPOPVx+/0VZVFPshkuuAjBp9vIxhJlkBeqZtDCKNr tqpJjyu2imPlSLWAuIrg/zHg2nTVIYrIP3dNImpiYGrZuQgcPzFLv7DNIQn8YlnrDJS4 CBHZTOLKzdprB5PRkav4G6wuTTniU2B8hsiMTvl1FOZ+DyUqb2NtbbF1enHQ4eRz2X1M xVWRqxIPdWusiliQVpNbiesrvSQ+j1ojmMi+Qui+1wltBhUWUfQrYpOFi/lRagL+0iSU dQFA== 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 :content-id:mime-version:subject:cc:to:references:in-reply-to:from :organization:arc-authentication-results; bh=QA+i+I3Q/W6wmOLTqCgwBgF9WiYxWwHM0sRPCNZuuIY=; b=Yvzxzsy5gYtgyZ6Ud+ivzCQRUtINAio7kQcz7G5EAeLfcAySvrN2MbYBU76jFZBmOd Wlo24FQQlpBhHKzOibEp7INsAg3XAjJKHkFiIZj2Xr314xFt92bdq68sivRX5ySnWTcQ IJ239BoY0tjqvEeNEZFuXMPS+Rr6X0nYRPcMb/t4hCFFKKxNpDKWc0bYg3yyv6jb3PrL 28yaHqroo2FzKQoahX3900pVm94b2Zyhjh79NsIby9uvQMBlTcoaNf/1HUf/tf72y26K BLe1I7qmx8AXcmYxuuNk1ISnYJN4FWPYVwAjXQ/eJnHO43n6WP7b4y2xchw2SjKlBRf6 k4Rg== 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 y22si4754017plr.606.2018.01.17.08.35.25; Wed, 17 Jan 2018 08:35:39 -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; 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 S1754509AbeAQQek convert rfc822-to-8bit (ORCPT + 99 others); Wed, 17 Jan 2018 11:34:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59062 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754166AbeAQQeg (ORCPT ); Wed, 17 Jan 2018 11:34:36 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A0A2FC01B80F; Wed, 17 Jan 2018 16:34:36 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-120-87.rdu2.redhat.com [10.10.120.87]) by smtp.corp.redhat.com (Postfix) with ESMTP id E7087759F0; Wed, 17 Jan 2018 16:34:26 +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: <20180116193936.oiycvwlk5xy3gm77@dwarf.suse.cz> References: <20180116193936.oiycvwlk5xy3gm77@dwarf.suse.cz> <20180111120157.23qceywzi6omvvkb@dwarf.suse.cz> <151024863544.28329.2436580122759221600.stgit@warthog.procyon.org.uk> <151024869793.28329.4817577607302613028.stgit@warthog.procyon.org.uk> <20180111115915.dejachty3l7fwpmf@dwarf.suse.cz> <4582.1516120311@warthog.procyon.org.uk> To: Jiri Bohac Cc: dhowells@redhat.com, linux-security-module@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, jforbes@redhat.com, Chun-Yi Lee Subject: Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24617.1516206864.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Wed, 17 Jan 2018 16:34:24 +0000 Message-ID: <24618.1516206864@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 17 Jan 2018 16:34:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jiri Bohac wrote: > > If sig_err is -EKEYREJECTED, -EKEYEXPIRED or -EKEYREVOKED then it must fail, > > even if the signature check isn't forced. > > It wasn't my intention to fail in these cases. What additional > security does this bring? If simply stripping an invalid > signature from the image before loading will make it pass, why > should the image with an invalid signature be rejected? If there is a signature, then if we're checking signatures, in my opinion we should check it - and fail if the signature can't be parsed, is revoked, we have a key and the signature doesn't match - or even if we run out of memory. The cases for which enforcement is required are when (a) there is no signature, (b) we don't support the algorithms used, or (c) we don't have a key. If we're going to completely discard the result, why do your patches even bother to check the signature at all? David