Received: by 10.192.165.148 with SMTP id m20csp4579397imm; Tue, 8 May 2018 10:37:47 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrcsIK73f60OcHslGuJp8p2egeUeYLo4nzRR2AB9PvuC/OYKcEUV6vq/1HOe4EVVv0va5X0 X-Received: by 2002:a63:7f58:: with SMTP id p24-v6mr33264390pgn.290.1525801067214; Tue, 08 May 2018 10:37:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525801067; cv=none; d=google.com; s=arc-20160816; b=A+0O2IH9SIhKg9qFObeIDLYFWQMSGWjV7mh+S17JSgykcE7/4DFYDd0/VevOLyNR4v EXaIzb6rH6deJJ/IejvOPDPMv0jnb5cJlsGU1L86YDiibkzxpV5pFfNMXaL/hm11U35C eGFKMrUvlhNH8ugX5fnPfzx1VTE8P/yLm1SSenvBgipFB8iXRDZygAcQAT8i3gehGv8L Je0jla5Ak3Rz6M2+Vlb0djcEAlOTiXA/Gtd+0F1xOocJUYPVpYYIU/bfcID7cE1yRpTQ 4hGFa7H3U95l5sX16XgTMab5M6URdjj8HqQQuhp2YJo378URfL7uDWT5eWmR25Qs26W0 ZyVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=KT6owGCuhwRjJZYtdzMgWq5jyNZsfCPJS7os+stYG8s=; b=rnzIXm5t97puupr0tomNUElTU+JKUpa7iBrCgfSrPMAESCZXlOc8HCcgtpIuknPPU0 BtmjRrfT8bYz6VE+yG8v/If4ZdWe6N8vBxCeIhmyA7SCT4k6rzriL9CC1YBLcRWNug7v +pJ8Z8BcUw/ntJaj7vdYV98sLH8g1g4T+HzPO3+ZuNO7TYVrJJByuwfZIfb3oTISjT2R ibwkD4fEKqsZIXXcY+OTtNOJ+7wH6VJf2SJnSg77ByzT7PIeYkoFIDogMYaD/v0NltjC 2sDgCkyZX/A+vKlB0UBDhnh07EYmjFz6LPZnZ5BB8onmnLWbTR1nytZejVWEMAjFFQK4 esQA== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c12-v6si25363231plr.467.2018.05.08.10.37.32; Tue, 08 May 2018 10:37:47 -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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932204AbeEHReK (ORCPT + 99 others); Tue, 8 May 2018 13:34:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:46238 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754864AbeEHReI (ORCPT ); Tue, 8 May 2018 13:34:08 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 97119AAB2; Tue, 8 May 2018 17:34:05 +0000 (UTC) Date: Tue, 8 May 2018 17:34:04 +0000 From: "Luis R. Rodriguez" To: Mimi Zohar , linux-wireless , Kalle Valo , Seth Forshee , Johannes Berg Cc: "Luis R. Rodriguez" , linux-integrity@vger.kernel.org, Hans de Goede , Ard Biesheuvel , Peter Jones , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , Kees Cook , Greg Kroah-Hartman , Andres Rodriguez , Linus Torvalds , Andy Lutomirski Subject: Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware Message-ID: <20180508173404.GG27853@wotan.suse.de> References: <1525182503-13849-1-git-send-email-zohar@linux.vnet.ibm.com> <1525182503-13849-4-git-send-email-zohar@linux.vnet.ibm.com> <20180504000743.GR27853@wotan.suse.de> <1525393466.3539.133.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1525393466.3539.133.camel@linux.vnet.ibm.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 03, 2018 at 08:24:26PM -0400, Mimi Zohar wrote: > On Fri, 2018-05-04 at 00:07 +0000, Luis R. Rodriguez wrote: > > On Tue, May 01, 2018 at 09:48:20AM -0400, Mimi Zohar wrote: > > > Allow LSMs and IMA to differentiate between signed regulatory.db and > > > other firmware. > > > > > > Signed-off-by: Mimi Zohar > > > Cc: Luis R. Rodriguez > > > Cc: David Howells > > > Cc: Kees Cook > > > Cc: Seth Forshee > > > Cc: Johannes Berg > > > --- > > > drivers/base/firmware_loader/main.c | 5 +++++ > > > include/linux/fs.h | 1 + > > > 2 files changed, 6 insertions(+) > > > > > > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > > > index eb34089e4299..d7cdf04a8681 100644 > > > --- a/drivers/base/firmware_loader/main.c > > > +++ b/drivers/base/firmware_loader/main.c > > > @@ -318,6 +318,11 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv) > > > break; > > > } > > > > > > +#ifdef CONFIG_CFG80211_REQUIRE_SIGNED_REGDB > > > + if ((strcmp(fw_priv->fw_name, "regulatory.db") == 0) || > > > + (strcmp(fw_priv->fw_name, "regulatory.db.p7s") == 0)) > > > + id = READING_FIRMWARE_REGULATORY_DB; > > > +#endif > > > > Whoa, no way. > > There are two methods for the kernel to verify firmware signatures. Yes, but although CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is its own kernel mechanism to verify firmware it uses the request_firmware*() API for regulatory.db and regulatory.db.p7s, and IMA already can appraise these two files since the firmware API is used. As such I see no reason to add a new ID for them at all. Its not providing an *alternative*, its providing an *extra* kernel measure. If anything CONFIG_CFG80211_REQUIRE_SIGNED_REGDB perhaps should be its own stacked LSM. I'd be open to see patches which set that out. May be a cleaner interface. >?If both are enabled, do we require both signatures or is one enough. Good question. Considering it as a stacked LSM (although not implemented as one), I'd say its up to who enabled the Kconfig entries. If IMA and CONFIG_CFG80211_REQUIRE_SIGNED_REGDB are enabled then both. If someone enabled IMA though, then surely I agree that enabling CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is stupid and redundant, but its up to the system integrator to decide. If we however want to make it clear that such things as CONFIG_CFG80211_REQUIRE_SIGNED_REGDB are not required when IMA is enabled we could just make the kconfig depend on !IMA or something? Or perhaps a new kconfig for IMA which if selected it means that drivers can opt to open code *further* kernel signature verification, even though IMA already is sufficient. Perhaps CONFIG_ENABLE_IMA_OVERLAPPING, and the driver depends on it? > Assigning a different id for regdb signed firmware allows LSMs and IMA > to handle regdb files differently. That's not the main concern here, its the precedent we are setting here for any new kernel interface which open codes firmware signing on its own. What you are doing means other kernel users who open codes their own firmware signing may need to add yet-another reading ID. That doesn't either look well on code, and seems kind of silly from a coding perspective given the above, in which I clarify IMA still is doing its own appraisal on it. > > > fw_priv->size = 0; > > > rc = kernel_read_file_from_path(path, &fw_priv->data, &size, > > > msize, id); > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > > index dc16a73c3d38..d1153c2884b9 100644 > > > --- a/include/linux/fs.h > > > +++ b/include/linux/fs.h > > > @@ -2811,6 +2811,7 @@ extern int do_pipe_flags(int *, int); > > > id(FIRMWARE, firmware) \ > > > id(FIRMWARE_PREALLOC_BUFFER, firmware) \ > > > id(FIRMWARE_FALLBACK, firmware) \ > > > + id(FIRMWARE_REGULATORY_DB, firmware) \ > > > > Why could IMA not appriase these files? They are part of the standard path. > > The subsequent patch attempts to verify the IMA-appraisal signature, but on > failure it falls back to allowing regdb signatures. >?For systems that only want to load firmware based on IMA-appraisal, then >regdb wouldn't be enabled. I think we can codify this a bit better, without a new ID. Luis