From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752405AbdKIEnC (ORCPT ); Wed, 8 Nov 2017 23:43:02 -0500 Received: from mail-it0-f43.google.com ([209.85.214.43]:55789 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751728AbdKIEm7 (ORCPT ); Wed, 8 Nov 2017 23:42:59 -0500 X-Google-Smtp-Source: ABhQp+RIQWdG79WwTze2myWJO7F3C5z86+gsOdwP97VVNFJDnLtsISaXxsxs9stxIh3qXA4lHYDTaw== Date: Thu, 9 Nov 2017 13:46:21 +0900 From: "AKASHI, Takahiro" To: Mimi Zohar Cc: "Luis R. Rodriguez" , Greg Kroah-Hartman , Linus Torvalds , Jan Blunck , Julia Lawall , David Howells , Marcus Meissner , Gary Lin , linux-security-module@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk, linux-efi , linux-kernel@vger.kernel.org, Matthew Garrett Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown Message-ID: <20171109044619.GG7859@linaro.org> Mail-Followup-To: "AKASHI, Takahiro" , Mimi Zohar , "Luis R. Rodriguez" , Greg Kroah-Hartman , Linus Torvalds , Jan Blunck , Julia Lawall , David Howells , Marcus Meissner , Gary Lin , linux-security-module@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk, linux-efi , linux-kernel@vger.kernel.org, Matthew Garrett References: <1509660086.3416.15.camel@linux.vnet.ibm.com> <150842463163.7923.11081723749106843698.stgit@warthog.procyon.org.uk> <14219.1509660259@warthog.procyon.org.uk> <1509660641.3416.24.camel@linux.vnet.ibm.com> <20171107230700.GJ22894@wotan.suse.de> <20171108061551.GD7859@linaro.org> <20171108194626.GQ22894@wotan.suse.de> <20171109014841.GF7859@linaro.org> <1510193857.4484.95.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1510193857.4484.95.camel@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mimi, On Wed, Nov 08, 2017 at 09:17:37PM -0500, Mimi Zohar wrote: > > > IMHO that should just fail then, ie, a "locked down" kernel should not want to > > > *pass* a firmware signature if such thing could not be done. > > > > > > Its no different than trying to verify a signed module on a "locked down" for > > > which it has no signature. > > > > > > But perhaps I'm not understanding the issue well, let me know. > > > > My point is quite simple: > > my_deviceA_init() { > > err = request_firmware(&fw, "deviceA"); <--- (a) > > if (err) > > goto err_request; > > > > err = verify_firmware(fw); <--- (b) > > if (err) > > goto err_verify; > > > > load_fw_to_deviceA(fw); <--- (c) > > ... > > } > > > > As legacy device drivers does not have (b), there is no chance to > > prevent loading a firmware at (c) for locked-down kernel. > > > > If you allow me to bring in yet another function, say > > request_firmware_signable(), which should be used in place of (a) > > for all verification-aware drivers, that would be fine. > > I really don't understand why you need a new function.  The > request_firmware() eventually calls kernel_read_file_from_path(), > which already calls the pre and post LSM hooks. My assumption here is: 1) there are some less important and so security-insensitive firmwares, by which I mean that such firmwares won't be expected to be signed in terms of vulnerability or integrity. (I can't give you examples though.) 2) firmware's signature will be presented separately from the firmware blob itself. Say, "firmware.bin.p7s" for "firmware.bin" I don't think that the current security_kernel(_post)_read_file() scheme fit with this assumption very well. Thanks, -Takahiro AKASHI > IMA-appraisal is already on these hooks verifying the requested > firmware's signature.  For systems with "lockdown" enabled, but > without IMA-appraisal enabled, define a small, builtin LSM that sits > on these LSM hooks and denies the unsigned firmware requests. > > Mimi > > > In this case, all the invocation of request_firmware() in legacy code > > could be forced to fail in locked-down kernel. > > > > But I think that "signable" should be allowed to be combined with other > > features of request_firmware variants like _(no)wait or _direct. > > > > -Takahiro AKASHI > From mboxrd@z Thu Jan 1 00:00:00 1970 From: takahiro.akashi@linaro.org (AKASHI, Takahiro) Date: Thu, 9 Nov 2017 13:46:21 +0900 Subject: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown In-Reply-To: <1510193857.4484.95.camel@linux.vnet.ibm.com> References: <1509660086.3416.15.camel@linux.vnet.ibm.com> <150842463163.7923.11081723749106843698.stgit@warthog.procyon.org.uk> <14219.1509660259@warthog.procyon.org.uk> <1509660641.3416.24.camel@linux.vnet.ibm.com> <20171107230700.GJ22894@wotan.suse.de> <20171108061551.GD7859@linaro.org> <20171108194626.GQ22894@wotan.suse.de> <20171109014841.GF7859@linaro.org> <1510193857.4484.95.camel@linux.vnet.ibm.com> Message-ID: <20171109044619.GG7859@linaro.org> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org Mimi, On Wed, Nov 08, 2017 at 09:17:37PM -0500, Mimi Zohar wrote: > > > IMHO that should just fail then, ie, a "locked down" kernel should not want to > > > *pass* a firmware signature if such thing could not be done. > > > > > > Its no different than trying to verify a signed module on a "locked down" for > > > which it has no signature. > > > > > > But perhaps I'm not understanding the issue well, let me know. > > > > My point is quite simple: > > my_deviceA_init() { > > err = request_firmware(&fw, "deviceA"); <--- (a) > > if (err) > > goto err_request; > > > > err = verify_firmware(fw); <--- (b) > > if (err) > > goto err_verify; > > > > load_fw_to_deviceA(fw); <--- (c) > > ... > > } > > > > As legacy device drivers does not have (b), there is no chance to > > prevent loading a firmware at (c) for locked-down kernel. > > > > If you allow me to bring in yet another function, say > > request_firmware_signable(), which should be used in place of (a) > > for all verification-aware drivers, that would be fine. > > I really don't understand why you need a new function.??The > request_firmware() eventually calls kernel_read_file_from_path(), > which already calls the pre and post LSM hooks. My assumption here is: 1) there are some less important and so security-insensitive firmwares, by which I mean that such firmwares won't be expected to be signed in terms of vulnerability or integrity. (I can't give you examples though.) 2) firmware's signature will be presented separately from the firmware blob itself. Say, "firmware.bin.p7s" for "firmware.bin" I don't think that the current security_kernel(_post)_read_file() scheme fit with this assumption very well. Thanks, -Takahiro AKASHI > IMA-appraisal is already on these hooks verifying the requested > firmware's signature. ?For systems with "lockdown" enabled, but > without IMA-appraisal enabled, define a small, builtin LSM that sits > on these LSM hooks and denies the unsigned firmware requests. > > Mimi > > > In this case, all the invocation of request_firmware() in legacy code > > could be forced to fail in locked-down kernel. > > > > But I think that "signable" should be allowed to be combined with other > > features of request_firmware variants like _(no)wait or _direct. > > > > -Takahiro AKASHI > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html