linux-kernel - Re: [RFD] linux-firmware key arrangement for firmware signing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 May 2015 16:14:19 +0100
From:	David Howells <dhowells@...hat.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	dhowells@...hat.com, linux-security-module@...r.kernel.org,
	james.l.morris@...cle.com, serge@...lyn.com,
	linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
	Kyle McMartin <kyle@...nel.org>,
	David Woodhouse <david.woodhouse@...el.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joey Lee <jlee@...e.de>, Rusty Russell <rusty@...tcorp.com.au>,
	zohar@...ux.vnet.ibm.com, mricon@...nel.org
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing

Luis R. Rodriguez <mcgrof@...e.com> wrote:

> This begs the question on how we'd manage keys for firmware signing on
> linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> initial discussions it would seem we'd need the Linux Foundation to create a
> key, this would be embedded in the kernel and that key would be used to sign
> Kyle's key.  Kyle would in turn use his key for signing linux-firmware
> files. David, Kyle, did I summarize this correctly ?

Yes.

> I think we need one change here, we'd need to ensure that such key could
> only be used for vetting firmware files, not modules loaded.  The
> firmware_class could for instance still use all the keys in
> system_trusted_keyring, which would include the UEFI key db, but it does not
> seems reasonable to expect keys used for fw signing to also go into
> system_trusted_keyring to also be used for module signing.

X.509 certificates can take attributes that define what the key held therein
may be used for.

You actually have four categories of key usage, I think:

 (1) Signing modules.

 (2) Signing firmware.

 (3) Signing kernel binaries for kexec.

 (4) Signing other keys that can then be chained to (1) - (3).

For instance, the LF might use their key to sign Kyle's key.  Kyle might want
to replace his key yearly, say, because the more examples of things signed
with it, the more exposed it becomes.  So the kernel would need to carry the
LF key, say, and then the appropriate one of Kyle's keys could be loaded
dynamically.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/