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

Powered by Openwall GNU/*/Linux Powered by OpenVZ