linux-kernel - Re: Should we automatically generate a module signing key at all?

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]

Message-ID: <5261.1432060684@warthog.procyon.org.uk>
Date:	Tue, 19 May 2015 19:38:04 +0100
From:	David Howells <dhowells@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	dhowells@...hat.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	keyrings@...ux-nfs.org
Subject: Re: Should we automatically generate a module signing key at all?

Andy Lutomirski <luto@...capital.net> wrote:

> > There is metadata selecting the particular key to be checked against, so
> > with a 512-byte signature, you get around 500 bytes of metadata and ASN.1
> > wrappings.  We could probably trim that some more by removing PKCS#7
> > attribute sections.
> 
> You could trim even more by simply not using PKCS#7.  A raw PKCS#1
> signature would be just fine.  (We should really be using PSS,
> though.)

Trimming the attributes reduces it to about 150 bytes over the signature.
PKCS#7 is handy because it's a standard that has standard ways of specifying
digest and crypto algorithms and key lookups.  Plus we need it available to
verify PE-signed kernel images.

> ...and for users who need to comply with unfortunate standards,

If you want to get into certain markets, you have to care.

> The kernel data involved is 32 bytes.

No, it isn't.  It's the entire hash list and whatever metadata it requires.
Dynamically loaded kernel data is *still* kernel data.

> I don't think that the needs of IMA users should affect normal people
> who run 'make' on their kernel tree.

The sad fact is that 'normal' Linux users use distribution kernels and don't
give two figs about how it does what it does (or use something like Android
and don't even realise Linux exists).  I'm not that sure people who build
their own kernels can really said to be 'normal' in this sense.

> Deterministic builds can't apply to firmware regardless, so users are
> trusting a vendor one way or another.  And for Chromebook or
> Atomic-like uses, hashes are fine.

That may be so, but that doesn't help Fedora, RHEL and suchlike that run on
less restricted hardware.  For an embedded platform, a monolithic kernel may
also be fine.

> Agreed, although I don't understand why UEFI is a reasonable place for
> firmware or module keys.  UEFI is a giant implementation detail,
> whereas module and firmware validation is really a cross-architecture
> thing.

Because it exists and we have to use it on many new machines, so we might as
well make best use of it if it's there.  Besides, if M$ have their way, it'll
be everywhere - even on your toaster;-)

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/