[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1432298525.2450.66.camel@linux.vnet.ibm.com>
Date: Fri, 22 May 2015 08:42:05 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: David Howells <dhowells@...hat.com>
Cc: Andy Lutomirski <luto@...capital.net>,
"Luis R. Rodriguez" <mcgrof@...e.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 Fri, 2015-05-22 at 08:56 +0100, David Howells wrote:
> Andy Lutomirski <luto@...capital.net> wrote:
>
> > Without tagging the purpose of the signed file, you simply don't have
> > a cryptographic guarantee of that. The bad guy can load something
> > else that was signed for an entirely different purpose into the wrong
> > device, possibly crashing it, causing buffer overflows because the
> > format is wrong, or doing any number of other bad things.
>
> One suggestion David Woodhouse made with regard to tagging is that the tag
> could just be added into the digest before it is signed/verified and not
> actually stored in the signature.
>
> This means that if you try loading the firmware for the wrong request, the
> signature verification will fail.
>
> It's an interesting approach that's simple to achieve, but it has the downside
> that the signature will be invalid in the mismatch situation and you can't
> tell whether it's because the module is being misused or the signature is just
> wrong. However, that might be livable with.
With transitive trust, any key on the system keyring would be able to
add keys with any tag, whether the tag is in the cert or the digest. If
I trust cert A to sign keys that add kernel modules or other certs that
add kernel modules, it doesn't mean that I trust that cert to also sign
keys that add firmware, for example, or other keys that add firmware.
Mimi
--
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