linux-kernel - Re: [GIT PULL] Load keys from signed PE binaries

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, 27 Feb 2013 10:17:16 +0000
From:	James Courtier-Dutton <james.dutton@...il.com>
To:	ownssh <ownssh@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Load keys from signed PE binaries

On 27 February 2013 09:35, ownssh <ownssh@...il.com> wrote:
> David Howells <dhowells <at> redhat.com> writes:
>
>>
>>
>> Florian Weimer <fw <at> deneb.enyo.de> wrote:
>>
>> > Seriously, folks, can we go back one step and discuss what problem you
>> > are trying to solve?  Is it about allowing third-party kernel modules
>> > in an environment which does not allow unsigned ring 0 code execution?
>>
>> Let me try and lay things out:
>>
>>  (1) Like it or not, the reality is that machines exist that have UEFI secure
>
> I think, redhat should have their own root key to sign binary files.
> Bootloader of install media can be sign by MS certificates, but only use to add
> the redhat root key to UEFI database before install.
> It will solve many problems like MS blacklist the keys although redhat said MS
> wont do that forever.
>
> And, even you do the all things of A-G, it still wont safe because many
> vulnerabilities can let the attacker enter ring0 only use to exploit the exist
> signed kernel module or kernel itself.
>

One way to judge if this is a good solution or not is to list what the
threats are, and see how well the solution mitigates those.
I will list a few I would like:
1) Tamper evindence.
2) Fast trust revokation and correction.
3) Trust based on date. I trust everything from X that I put on my
system 2 weeks ago, but one week ago X got hacked, so don't trust
anything new from them until the hack has been stopped and the
revokation/correction steps have been completed.
E.g. the Bit9 case, where malware was able to be signed.

I think secure boot does a very week version of (1) and is very slow
at (2), and does not do (3).
The ARM version of secure boot is maybe slightly better, it does a
good job of (1) but at the expense some of (2).
I.e. the root certificate is in ROM on ARM and not EEPROM on x86.
It is difficult to tamper with ROM, so you have a much stronger tamper
evindence solution.
Unfortunately, if the root certificate in the ROM is compromised, you
cannot revoke it and correct it.

Kind Regards

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