linux-kernel - Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

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 08:56:21 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Howells <dhowells@...hat.com>
Cc:	Andy Lutomirski <luto@...nel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Michal Marek <mmarek@...e.cz>,
	Matthew Garrett <mjg59@...f.ucam.org>, keyrings@...ux-nfs.org,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Luis Rodriguez <mcgrof@...e.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On Wed, May 20, 2015 at 6:36 AM, David Howells <dhowells@...hat.com> wrote:
> Andy Lutomirski <luto@...nel.org> wrote:
>
>> I think this is way more complicated than it has to be.  Can't we look up
>> certificates by their subjectPublicKeyInfo?
>
> I want to be able to handle an X.509 chain to a root key that we have in the
> kernel.  X.509 certs don't chain on subjectPublicKeyInfo unless that happens
> to be what's in the SKID (which is a pretty indefinite standard in its own
> right:-( ).  So we need to be able to match on the two things I made available
> anyway.  PKCS#7 matches on one of them too, so that then just works.

I see.  PKCS#7 (and PKCS#6 and X.509 which it inherits from) is too
dumb to identify the public key that signed a certificate, so you
can't match on it.  Sigh.

That being said, are you actually planning on implementing X.509 chain
validation correctly?  ISTM you can't really do it usefully, as we
don't even know what time it is when we run this code.  What's the
point of accepting certificate chains if there's no meaningful
validation we can do?

>
>> Why is PKCS#7 better than whatever we're using now?
>
> It has a standard form[*].  It has standard ways to specify things such as the
> key to use and the digest to use.  It can carry multiple signatures from
> different keys and can carry key chains (something that's more likely to be
> useful for kexec or firmware, admittedly).  It can be generated by extant
> tools (though adding it onto a module needs a special tool).

Given how much special stuff is needed (special tool to append it,
probably weird or absent certificate chain validation, etc), this
seems to me to be of questionable value.

Would it make more sense to permit X.509 chains to be loaded into the
keyring instead if we actually need that feature?  IOW, let userspace
(or early initramfs stuff) extend our keyring trust to intermediate
certs that validly chain to already-trusted things?  I think that a
reasonable design goal would be that everything overcomplicated that's
involved should be optional, and moving toward embedding PKCS#7
signatures in the modules themselves does the other direction?

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