Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp5071105imm; Mon, 14 May 2018 19:03:26 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqpbbeOB2sEFHYzYZv46qe5nV0DtjQwjadSXzzzIU3oNE+vWsq0y8MT+x87xz/H3OXgRGfE X-Received: by 2002:a17:902:968d:: with SMTP id n13-v6mr11872788plp.168.1526349806683; Mon, 14 May 2018 19:03:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526349806; cv=none; d=google.com; s=arc-20160816; b=US8vJQJg3NzKiZVVy9HhPdeaqcu+vlNvw8U96x7iIUJfboK85EUGRYz0bczhUh48b0 z+5UpI0/D9MWJKbCMsvdO3IfCeIGB+ChR24AAR6yOY7fdx6l7h3Rveofb7OQ1MfPFDrO nnOelcqCmJROFq8HCDNbGAjo+jJafQdoV3hGv0yIzn/Y0gRPuVJTvMxW02jezNNjvpir QamvP/lfyMtf11D4SV17gj//4oObDhern4JVMReOS4jAmoFeU6jKZuyRh1vh5pdYANmw I1nfdtmiM8p90SZ2DjfLC/hoC6wJwPJ6UhWuiHGNlILLJ7WLFI7zmievwQAKfb7Hf5pQ RxXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:references:in-reply-to:date:cc:to:from:subject :arc-authentication-results; bh=cM0C2e4t99/apY1frVuYXfsrFH79ztN3kOLOHLEnHdc=; b=mZnrmSdmwoZ4CLiqpi1kRsZ3IlAWmcQnBibBXL0yOiUJiG1V1wyktVRZ+OWlxbGpm6 kcRgIXkWyKH2w/YitKMKK1US96H4r/sIzHYjDbN6SWHw+aRCkg8iZo665LaOsdNQzZcH MZtdST0bkbEsvjYWhJYh7Y9abi6xIpVHCnXZIdKxjI/w25TBJNS4eggRrmTl/MJw1Q1P Mo+c9GXBdPD8SoNO5cSKbsA/Rke8mPCtI0fFIGyvux9nNRQRv1XnoX9J0W3oQJ8kANNR kzeY0qT6rBMGB025nBvRYI2AeraQGMed6Hw5mys+6XZkyP837LroJmoBXxlUCO84Cy4Y 950A== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 36-v6si11193724plb.140.2018.05.14.19.03.12; Mon, 14 May 2018 19:03:26 -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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752489AbeEOCDA (ORCPT + 99 others); Mon, 14 May 2018 22:03:00 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52080 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752348AbeEOCC6 (ORCPT ); Mon, 14 May 2018 22:02:58 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4F1sbZx053698 for ; Mon, 14 May 2018 22:02:57 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0b-001b2d01.pphosted.com with ESMTP id 2hyjrky384-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 14 May 2018 22:02:57 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 15 May 2018 03:02:54 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 15 May 2018 03:02:46 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4F22jQ938797320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 May 2018 02:02:45 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F19134C05A; Tue, 15 May 2018 02:54:37 +0100 (BST) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7EB634C046; Tue, 15 May 2018 02:54:34 +0100 (BST) Received: from localhost.localdomain (unknown [9.80.107.234]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 15 May 2018 02:54:34 +0100 (BST) Subject: Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware From: Mimi Zohar To: "Luis R. Rodriguez" , Harald Hoyer , Hannes Reinecke , Johannes Thumshirn Cc: "Eric W. Biederman" , Casey Schaufler , Alexei Starovoitov , David Miller , Jessica Yu , Al Viro , One Thousand Gnomes , Matthew Garrett , Peter Jones , "AKASHI, Takahiro" , David Howells , linux-wireless , Kalle Valo , Seth Forshee , Johannes Berg , linux-integrity@vger.kernel.org, Hans de Goede , Ard Biesheuvel , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Kees Cook , Greg Kroah-Hartman , Andres Rodriguez , Linus Torvalds , Andy Lutomirski Date: Mon, 14 May 2018 22:02:31 -0400 In-Reply-To: <20180514192853.GM27853@wotan.suse.de> References: <20180509191508.GR27853@wotan.suse.de> <1525895838.3551.247.camel@linux.vnet.ibm.com> <20180509212212.GX27853@wotan.suse.de> <1525903617.3551.281.camel@linux.vnet.ibm.com> <20180509234814.GY27853@wotan.suse.de> <1525917658.3551.322.camel@linux.vnet.ibm.com> <20180510232639.GF27853@wotan.suse.de> <1526014826.3414.46.camel@linux.vnet.ibm.com> <20180511215250.GJ27853@wotan.suse.de> <1526302692.3898.145.camel@linux.vnet.ibm.com> <20180514192853.GM27853@wotan.suse.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18051502-0012-0000-0000-000005D695D1 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051502-0013-0000-0000-00001953AF90 Message-Id: <1526349751.3937.78.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-14_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805150017 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-05-14 at 19:28 +0000, Luis R. Rodriguez wrote: [...] > > At runtime, in the case > > that regdb is enabled and a custom policy requires IMA-appraisal > > firmware signature verification, then both signature verification > > methods will verify the signatures.  If either fails, then the > > signature verification will fail. > > OK so you're saying that if CONFIG_IMA_APPRAISE_FIRMWARE is disabled you can > still end up with CONFIG_CFG80211_REQUIRE_SIGNED_REGDB as enabled *and* a > custom policy which requires IMA-appraisal for the certain firmware signature > verifications? Right > > There are two problems: > > - there's no way of configuring a builtin policy to verify firmware > > signatures. > > I'm not too familiar with IMA however it sounds like you can extend the IMA > built-in policy on the boot command line. No, there are a couple of policies predefined in the kernel that can be loaded by specifying them on the boot command line.  A custom policy can be loaded later.  Only after specifying a policy on the boot command line or loading a custom policy, does IMA do anything. > > - CONFIG_IMA_APPRAISE is not fine enough grained. > > > > The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option.  Similar > > Kconfig options will require kernel modules, kexec'ed image, and the > > IMA policy to be signed. > > Sure, it is still unclear to me if CONFIG_IMA_APPRAISE_FIRMWARE will be > doing firmware verification in userspace or in the kernel. The kernel is verifying signatures. > > There are a number of reasons that the kernel should be verifying > > firmware signatures (eg. requiring a specific version of the firmware, > > that was locally signed). > > Oh I agree, Linux enterprise distributions also have a strong reason to > have this, so that for instance we only trust and run vendor-approved > signed firmware. Otherwise the driver should reject the firmware. Every > now and then enterprise distros may run into cases were certain customers > may run oddball firmwares, and its unclear if we expect proper functionality > with that firmware. Having some form of firmware signing would help with > this pipeline, but this is currently dealt with at the packaging, and > noting other than logs ensures the driver is using an intended firmware. > But these needs *IMHO* have not been enough to push to generalize a kernel > firmware signing facility. In order for IMA-appraisal to verify firmware signatures, the signatures need to be distributed with the firmware.  Perhaps this will be enough of an incentive for distros to start including firmware signatures in the packages. > If CONFIG_IMA_APPRAISE_FIRMWARE is going to provide this functionality somehow > I'm happy to hear it. The functionality has been there since commit 5a9196d ("ima: add support for measuring and appraising firmware").  The security_kernel_fw_from_file() hook was later replaced with the generic security_kernel_read_file() hook. Mimi