On 12/22/22 12:33, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi <bl...@debian.org> wrote:
>>
>>> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>>> <mzerqung(a)0pointer.de&gt; wrote:
>>>
>>> Basically, I'm saying that the model of trust is flawed because users
>>> are unable to work with it.
>>>
>>> And besides, each level up is a smaller scope from the previous. A
>>> cert trusted by shim can execute anything the firmware trusts, a cert
>>> trusted by grub can only execute things it trusts, and finally a cert
>>> trusted by the OS can only execute things in its context. Once we
>>> reach the OS-level, we don't need pre-boot trust anymore. So enrolling
>>> certificates to trust kernel modules/sysexts/etc. should not require
>>> going down the trust levels. The OS should be able to establish its
>>> own trust to those pieces or reject them independently. It should
>>> certainly trust everything the lower levels trust, but there's no
>>> reason to not allow the higher levels to establish their own scoped
>>> trust.
>>>
>>> This is the flaw we have right now: we can't do that.
>>
>> Of course there's a reason to only allow a fully validated trust chain -
>> not only that, but it's the very basic of the entire model, and without
>> it the entire premise falls flat on its face.  The way to enroll your own
>> certs is via firmware-mediated mechanisms such as shim+mok, and via
>> built-in trusted keyring. Adding arbitrary trust anchors at the OS level
>> completely ignores the foundational principle of the whole thing.
> 
> Your concept only works in *some* enterprise hardware where it's even
> possible to have full control without breaking something. Even in my
> server gear, I can't do that without breaking the network firmware.

What???  That is strange.

> If I can't safely distrust Microsoft reliably, then it's already broken.

Absolutely.  Otherwise, an attacker can just boot into Windows and
use any of the numerous bring-your-own-vulnerable-driver exploits to
get code execution in the kernel.  To stop this, one needs to remove
the Microsoft signing key from the root store.

> Firmware trust has been broken since the very beginning, and it was
> broken by design in the PC world.
> 
> Consumer PC equipment is even worse off because of how Microsoft's
> Windows requirements influence how UEFI implementations work.

IMO a much more realistic approach for bare hardware is measured boot,
using Dynamic Root of Trust for Measurement (DRTM) where available.
The latter is the basis of Qubes OS’s Anti Evil Maid.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to