Use a UEFI locked down variable to allow self-signed forks of System informer to use the original signed driver

[DavidXanatos]

Windows uses a locked down UEFI variable to persistently set a protection option for the lsass.exe as described here: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

I was wondering if you could consider using an analogous approach to empower users to make the choice if they want to allow self-signed system informer forks to use the original signed driver.
Setting a Variable from the UEFI environment using a special tool would be quite the statement of undeniable ownership over the system.

On a quick glance over the UEFI specification I'm not sure if the mechanism used for lsass.exe would work here as we would want something inverse, i.e. only to be set from a UEFI tool not only to be cleared by one.
So in case that's not doable this way, one could go the overkill route and enroll an own certificate as the Platform Key and system informer would then test the *.sig files also against that key.

What do you think would that be a secure enough to allow lore freedom to the users?

[dmex]

UEFI variables can be created and changed by unauthenticated users without administrative access?

[DavidXanatos]

Once ExitBootServices() is performed, only variables that have EFI_VARIABLE_RUNTIME_ACCESS and
EFI_VARIABLE_NON_VOLATILE set can be set with SetVariable(). Variables that have runtime access
but that are not nonvolatile are read-only data variables once ExitBootServices() is performed. When the
EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS attribute is set in a SetVariable() call, the au-
thentication shall use the EFI_VARIABLE_AUTHENTICATION_3 descriptor, which will be followed by any
descriptors indicated in the Type and Flags fields

from https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf

So we could allow a user to install a custom Bootloader, with or without secure boot (they can sign it and install the own key in the UEFI) which would set a variable with the aforementioned configuration to eider disable the advanced security of the driver entirely or replace the hardcoded public key with one provided by the user, and then proceed to run the windows bootloader.

This sounds to me like a quite secure approach, in the end if an attacker has control over the boot process they can use efiguard (https://github.com/Mattiwatti/EfiGuard) or a custom boot kit to compromise any security they may desire anyways.

So allowing a volatile read only flag to be set by the Bootloader seams like an approach which would empower the user to exert ownership over their device without exposing any new attack vectors, wouldn't it?

[DavidXanatos]

sooo....??? still not convinced?