Message-ID: <CALCETrX3krCsqCLvLYx1QdnjFK=R8FF7ta=vozDcGYSTUHvSrA@mail.gmail.com>
Date:	Thu, 21 May 2015 09:39:50 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Howells <dhowells@...hat.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>, Joey Lee <jlee@...e.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Kyle McMartin <kyle@...nel.org>,
	Sedat Dilek <sedat.dilek@...il.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Konstantin Ryabitsev <mricon@...nel.org>,
	Michal Marek <mmarek@...e.cz>,
	Seth Forshee <seth.forshee@...onical.com>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	David Woodhouse <david.woodhouse@...el.com>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	James Morris <james.l.morris@...cle.com>,
	keyrings@...ux-nfs.org, Abelardo Ricart III <aricart@...nix.com>,
	"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing

On May 21, 2015 8:52 AM, "David Howells" <dhowells@...hat.com> wrote:
>
> Luis R. Rodriguez <mcgrof@...e.com> wrote:
>
> > I had this planned out because regulatory.bin used its own simple RSA key
> > with no x509 juju magic. I also envisioned it being easier for Kyle for
> > instance to use his own PGP key to sign linux-firmware files to start off
> > with than some complex x509 thing. Based on discussions with David, Seth,
> > and Kyle though it seems we were going to be happy with trusting Kyle's key
> > for regulatory.bin, since that will be done Kyle might as well sign all
> > linux-firmware files and folks who trust that can use it.
>
> To go down the signature root, what the kernel needs is:
>
>  (1) A way to get a key into the kernel.  We're currently using X.509 for this
>      for module signing and kexec.
>
>  (2) A way to get a signature into the kernel with sufficient metadata to
>      select the key to use.  Currently, kexec uses PKCS#7 for this and module
>      signing uses a private format which I'm intending to change to PKCS#7.

I think PKCS#7 doesn't even solve the problem we actually need to
solve, which is that we want to trust the wireless regulatory key for
regulatory.bin but nothing else.  Keep in mind that every attempt to
do this for web CAs using X.509 has failed miserably (Google "name
constraints"), whereas having a trivial set if flags associated with
any key format whatsoever in the kernel would solve it fully.

Just track a list of allowed purposes for each key.  If we really
really need cert chains, restrict the child to be a subset of the
parent, which is something that X.509 thoroughly screwed up.

>
>      For firmware, I think Andy is right and we also need to include in the
>      metadata something that says under what circumstances the firmware can be
>      used - likely the name that is passed to request_firmware() - which must
>      also be included in the digested data.
>
>      I don't believe that module signing actually requires a hint of this type
>      since we have to permit insmod to work and there won't be a hint we can
>      trust.  Besides, once verified, modules have to be loadable by the module
>      loader which is probably a sufficient restriction in itself.
>

Famous last words: "Is probably a sufficient restriction".  Let the
crypto do its job -- the bad guys are almost certainly more clever
than the module loader.

I think that we neither can nor should check the module name against a
tag -- the module name is part of the signed module payload.

>      I don't believe that kexec signing requires a name hint either since I
>      think the only restriction on what we're allowed to kexec is that it must
>      be bootable from the beginning - and must be a PE binary on x86 type
>      platforms.
>
> I do have patches to parse PGP key data and add the public keys found therein
> onto the kernel keyring, but that would mean adding an extra key data parser.

Why would this have to live in the kernel?  If you want to add a key
to the keyring, feed the raw key to the keyring along with some reason
to trust the key.  There's no need to stick OpenPGP in the kernel.

I think we're all (except maybe Luis) too stuck on key/cert formats.
Kyle wants to use OpenPGP.  You want to use PKCS#7.  Some people want
to use PKCS#11 with whatever wrapper.  Probably someone out there
wants to use the SSH infrastructure.  Who cares?  As long as we keep
using PKCS#1 v1.5 as the underlying technology, all of these are
exactly equivalent.

Some day soon we should move away from PKCS#1 v1.5 as our preferred
technology, at which point either we still support it for legacy
purposes or we have to update the tooling.  But I really think that
the tooling should be just that: tooling.

The single reasonably exception I've heard is that we need to support
Authenticode for kexec.  I don't really believe that entirely --
surely we can produce a kernel image that is both validly signed using
Authenticode *and* validly signed with our internal format.  Or we can
have a separate special-case parser for Authenticode-signed kexec
images and we can turn it off for users who don't want it (which
presumably includes everyone using things like Quark, which is a
bizarre architecture that is extremely memory-constrained but
nonetheless supports Secure Boot).

>
> You could probably do this with the integrity functions - but turning them on
> has a performance cost and you have to load things in the right order as I
> understand it.

It's also a performance cost because the average user of this
signature stuff doesn't actually want IMA, and IMA is checking the
wrong think anyway.  IMA/EVM tells us "this file validly belongs in
/lib/modules/whatever according to whomever we trust for the
filesystem".  We want to check "is this data, regardless of where it
was read from, a trusted module".

>
> The hash list idea for firmware really isn't a starter for a distribution like
> Fedora and especially RHEL.  We would have to crank out a new set of kernels
> any time anyone released a new firmware that someone might want to load since
> the hash list is effectively dependent on *all* the firmware blobs.  Further,
> you cannot ever discard any entries as you would potentially prevent someone's
> system from booting if you did.

Can we please stop beating this dead horse?  AFAIK no one ever
suggested using a has list for firmware in the first place.

>
> > > 3. PKCS#1 v1.5, really?  PKCS#1 v1.5 is known to be insecure unless
> > > very cafefully validated.  For example:
> > >
> > > https://www.imperialviolet.org/2014/09/26/pkcs1.html
> > >
> > > Could we please consider using a signature scheme with a security proof?
> >
> > I'm fine with going with some other alternative, now what do you have in mind?
>
> We can look at moving to PKCS#1 v2.1 and using RSASSA-PSS.  The main
> difficulty is persuading openssl that it wants to do that.
>

openssl pkeyutl appears to support PSS.

> Andy Lutomirski <luto@...capital.net> wrote:
>
> > RSA-PSS, ECDSA over P-256, or Ed25519.  The IRTF CFRG is expected to
> > publish an RFC for a modern signature scheme any day^Wmonth^Wyear now,
> > too.
>
> These are public key algorithms, not message/certificate formats, so comparing
> X.509 or PKCS#7 to ECDSA or Ed25519 is not valid.

Sure it is, because we don't actually seem to need a fancy
message/certificate format in the first place.

--Andy
--
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/

Powered by blists - more mailing lists