Last time I was starting vanishing of Ethan Carter, but even though it was playable, the experience wasn't free of stutters, whereas windows ran flawlessly.
In any case, it is always nice to jump back and check out how far Linux has come.
I'm of course ignoring the fact that a lot of Linux distros still do not have Secure Boot enabled by default, and therefore do not enforce any kernel driver signing policy.
Can the same certificate be used to cause supply chain attacks?
[1] https://distrowatch.com/search.php?pkg=shim&relation=lessequ...
Everyone can load their own signing keys into firmware. However, if you want something that "just works", Microsoft signs a package called Shim[1] that can be loaded on most computers due to the pre-loaded keys.
A relationship with Microsoft is not needed in any way or form to have Secure Boot.
As for Windows packages, there are several "package" systems:
- AppInstaller (winget): A SHA256 hash is included in the application manifest. I might be wrong, but I do not believe the manifests are signed afterwards. Packages are verified upon installation.
- MSIX packages: They are signed and timestamped with a publisher certificate. They are verified upon installation.
- Executables: Not really packages as such, but PS1 scripts and .EXE executables support Authenticode signatures. They are verified upon execution.
As for Linux, there are several package systems:
- DPKG/DEB: Built-in support for verification with hashes generated at install time. Packages can be GPG signed for stronger security, but it is disabled by default. Repository metadata is often GPG signed.
- RPM: Like DEB above it supports verification with MD5. It also has GPG integration. I believe it is disabled by default as well.
Linux does unfortunately not have support for signatures of ELF executables.
Fortunately. This whole pseudo security brings nothing.
People scream about right to repair. When certificate is revoked or has expired your computer will stop working. It's that simple.
UEFI with Secure Boot enabled will only load the stage 1 bootloader if it is signed with the firmware trusted certificate. We don't know if this component is malicious, we just know it is signed by the certificate.
The stage 1 bootloader (shim) will then be responsible for loading the next component (stage 2 bootloader). It will only boot the component if it is signed with a trusted (chosen by the user/distro) certificate.
The bad guys can't insert themselves into this process, as they either have to be trusted by the UEFI firmware (protected by an owner password), signed by Microsoft (to replace the shim) or be signed by the distro's certificate.
As long as the chain is unbroken it is secure.
There is nothing in Secure Boot that prevent people from running their own software. You can update the Secure Boot DB/DBX with whatever you want. Yes, the certificates expire - my computer was bought 4 years ago and Microsoft's UEFI CA will expire in 4 years. At that point I will probably have bought a new computer, but if I have not, I can update the certificate to the new one they released.
Secure Boot is very much an improvement over non-secure booting, and Authenticode signing is an extension of that security to enable signed-only software to run.
Pegasus.
AFAIK if a manufacturer wants to sell Windows PC, it has to support secure boot.