linux-kernel - Re: [PATCH 0/6] MODSIGN: Kernel module signing

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: <20070216001504.GA20951@linux.suse.de>
Date:	Fri, 16 Feb 2007 01:15:04 +0100
From:	Olaf Kirch <okir@....de>
To:	Andreas Gruenbacher <agruen@...e.de>
Cc:	Valdis.Kletnieks@...edu, Dave Jones <davej@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	torvalds@...ux-foundation.org, herbert.xu@...hat.com,
	linux-kernel@...r.kernel.org, arjan@...radead.org,
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH 0/6] MODSIGN: Kernel module signing

On Thursday 15 February 2007 12:34, Valdis.Kletnieks@...edu wrote:
> On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said:
> > I agree, that's really what should happen. We solve this by marking
> > modules as supported, partner supported, or unsupported, but in an
> > "insecure" way, so partners and users could try to fake the support
> > status of a module and/or remove status flags from Oopses, and
> > cryptography wouldn't save us.
>
> Where cryptography *can* save you is that a partner or user can't fake a
> 'Suse Supported' signature without access to the Suse private key.

The user has control over the running kernel, and given enough time
and clue, can circumvent any protection mechanism the vendor comes
up with. And that's a good thing IMO, unless you believe in "trusted
computing" and all those Bigbrotherisms some agencies want to put
in your machines.

So the user is running a system in some state that may or may not
resemble what the vendor shipped. When the machine crashes, the
user is free to munge the oops until it looks like a valid one.

Someone mentioned in this context that you can sign the oops - but to
do that you need a private key. And the whole point of this exercise is
that the user does not have access to that key.

So as far as support is concerned, you're back in square one.
You cannot tell a "genuine" oops produced on a supported kernel
from a doctored one produced on Joe Doe's Garage Kernel.

Olaf
-- 
Olaf Kirch        |  Anyone who has had to work with X.509 has probably
okir@....de       |  experienced what can best be described as
------------------+  ISO water torture. -- Peter Gutmann
-
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/