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:	Thu, 21 May 2015 15:06:21 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	David Howells <dhowells@...hat.com>,
	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>,
	"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 Thu, May 21, 2015 at 2:59 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> On Thu, May 21, 2015 at 2:44 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>
>> One option would be to add another type of verifiable thing.  We can
>> verify modules, and we should add firmware to the types of things that
>> can be signed.  We could add signing keys, too.  IOW, you could ask
>> the kernel to load a signing key with certain rights, and, if they key
>> is validly signed by some other key that has the same rights and has a
>> bit set saying that it can delegate those rights, then the kernel will
>> add that signing key to the keyring.
>>
>> If the general infrastructure were there, this would be very little
>> additional code.
>
> I really like this idea, but I've heard of many great ideas before
> followed by nothing but vaporware. So is it a direct requirement to
> implicate blocking a change for current module signature checking
> strategy to a new one given the concerns you raise, or can we enable
> those who wish to want additional better solutions as the one you
> propose to opt-in to develop those solutions? I like the idea of the
> later given that it seems those using the current module signing
> infrastructure would prefer the change and enabling what you say does
> not seem to be a not possible based on allowing that to be advanced.
>

>From my POV (and keep in mind that I'm not really involved in this
stuff and my POV shouldn't be treated as gospel), a firmware signature
verification should have verification that the signature was intended
to apply to a firmware file with the name being requested as a
requirement.  Everything else is nice-to-have.

Given that, I would say that merely shoving firmware files through the
module verifier as-is would not be okay.  There's plenty of
flexibility in how you fix it, though.  Doing it with PKCS#7
authenticated attributes *gag* would work, but my off-the-cuff guess
is that making that work is actually harder, even on top of David's
patches, than doing it from scratch.  PKCS#7 is not easy to work with.

FWIW, openssl rsautl can generate raw PKCS#1 v1.5 signatures (use
-pkcs, not -raw).  openssl pkeyutl can do PKCS#1 v2.0 (i.e. PSS)
signatures, but you'd have to write the verifier yourself.  The kernel
already has a v1.5 verifier that even follows the best practices that
I remember.  (For v2.0, there's a security proof, so an implementation
of the spec is actually secure and there are no "best practices" to
worry about.  v1.5 is known insecure if you implement it naively.)

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