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: <CALCETrVw9ZXi0==a3rhdE-ktBVxfdg5QbfmnA-KaNZRRxDBL9w@mail.gmail.com>
Date:	Tue, 19 May 2015 11:46:19 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Howells <dhowells@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	keyrings@...ux-nfs.org,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: Should we automatically generate a module signing key at all?

On May 19, 2015 11:38 AM, "David Howells" <dhowells@...hat.com> wrote:
>
> 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.
>

No, in the hash tree variant, it really is 32 bytes.  No one ever
needs the full list once the build is done.

> > 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.

Both Fedora and RHEL seems to be moving toward having fully-supported
configurations with immutable root images.  Building those images
reproducibly would be fantastic.  (Of course, if Fedora or RHEL wants
to allow support out-of-tree drivers, that's a different story.)

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