I can confirm that on both Lenovo and Dell, you can boot and install Fedora and Ubuntu without issue, but Manjaro (Arch) requires disable secure boot first, and on Dell you need to also disable AHCI (Raid) inside windows first (if you intend to keep your windows partition) or just disable in bios.
Otherwise it all works on latest XPS and X1 Extreme.
"Note: The official installation image does not support Secure Boot (FS#53864). To successfully boot the installation medium you will need to disable Secure Boot."
If you're using Arch you're probably willing to set up SB with your own keys.
(Heck, I use my own keys on OpenSUSE even though my distro signs the kernel, because I want to use systemd-boot instead of mokutil since the latter is broken on my motherboard.)
Yes but then it's up to the device admin typically to enroll some additional keychain into the enclave. I only know 1 group using the "trust 3rd party" over "trust ours" because they don't want users sticking mint on the company Ubuntu machines.
This is about using Secure Boot, not disabling it. The author wants to boot third party software, signed by Microsoft, but Lenovo disabled this unless you go in the firmware settings: they only allow software from Microsoft, not signed by them for third parties. As said elsewhere in the thread, it has no real use, except maybe delaying an attacker by a few seconds (and then again, that attacker won't access any data, so…).
> hey only allow software from Microsoft, not signed by them for third parties.
Not the entire picture here, that option is a part of a more holistic set of measures Microsoft calls Device Guard (part of Secured Core)
> it has no real use, except maybe delaying an attacker by a few seconds (and then again, that attacker won't access any data, so…).
It does prevent potential abuse of the signed shim that's not very difficult to get signed by. E.g. nobody can install the signed shim to rootkit a Windows installation.
> It does prevent potential abuse of the signed shim that's not very difficult to get signed by. E.g. nobody can install the signed shim to rootkit a Windows installation.
How would that worked if combined with FDE + TPM ?
For the average user, FDE is unlikely to be enabled by default. But yes, Secure Boot's measurements with BitLocker would prevent this as well.
Though seeing a recovery screen will not inform you that your bootloader has been tampered with and by entering a recovery key you're basically authorizing the malware to run.
Without FDE, modification of the file system to create autoruns and system services is so easy that you wouldn't need to go through the effort of using a bootloader. Just pop out the storage device or boot a Windows install disk and run some software.
>As said elsewhere in the thread, it has no real use, except maybe delaying an attacker by a few seconds
Does this not assume that the bios is not password protected, old dell laptops you need to jump 2 pins on the motherboard to bypass password protected bios and reset it. Don't think this works on newer ones.
> Disabling UEFI Secure Boot has been step 1 for installing Linux for as long as UEFI had existed, hasn't it?
Do you also log in to a desktop shell as root? Use "hunter2" as your SSH password? Run every random thing you download from the Internet?
Almost every sensible distro has been supporting secure boot for ages, and on things like Ubuntu it should just work out of the box, without the user ever noticing unless they dug. This is what TFA is complaining about - Lenovo broke it.
There is a signed grub bootloader out there that can be exploited through a crafted configuration file to do basically anything. Trusting the third party certificate is essentially trusting anything, you may as well disable it.
This is part of the design problem of secure boot, it only works if everyone updates their trusted key sets and motherboard manufacturers aren't exactly known for their plentiful, easy to install, reliable updates.
Microsoft should obsiously add a setting to enable normal secure boot ("Windows only", "allow Linux", "off") but it's not as if secure boot is much of a safety system for your average Linux user. You can configure a whole secure boot chain in Linux but enforcing that requires a lot of work that's not easily accessible. You'll also need to ensure you hook into the right update functions so your nvidia/AMD proprietary drivers are signed correctly or you won't be able to boot with a working display.
Well Secure Boot is very far from perfect. Personally I think a TOFU scheme (preloaded with OEM's own signature) would do 99% of the job, while keeping it less painful for the "I just want to install Ubuntu/Arch/GrumpyLinux" crowd. The machine's boot menu should just prompt the user to trust a vendor's key (e.g. not-now/never/once/forever), before booting it for the first time.
My reaction is because through all the unnecessarily complicated security measures (like SELinux, UAC, Secure Boot, etc) we've taught people to run to google for "Disable Secure $WHATEVER", which is a good indicator that the technology has failed to actually secure anything.
The best security is invisible. OpenBSD gets it. There are no "how to disable pledge" blog posts, because 1. pledge(2)[0] can't be easily disabled (you'd probably need to make a custom patch for the kernel to make the syscall a no-op); 2. there is no user-visible difference to doing do, because as long as the program is doing what it's expected to do, pledge is 100% invisible. This is how e.g. Secure Boot should have worked from day one, for everyone.
I know I'm kinda contradicting my earlier post here, but there's no reason to disable Secure Boot in 2022 any more, even if it failed to provide the security guarantees it promised.
Complaining about something that takes 30min to read up on.
Unless there was so much FUD out there about security and signing this would just be a minor hurdle to learning how to do security properly.
Yes mom&pop will never do it. But frankly. MOM&POP NEVER USED AN UBUNTU DISK TO INSTALL A CUSTOM DISTRO. They just used the laptop as provided by a trusted 3rd party. That will never change.
Disabling UEFI Secure Boot has been step 1 for installing Linux for as long as UEFI had existed, hasn't it?
What exactly is the problem here? I remember doing the same when installing Ubuntu on an ASUS laptop like 10 years ago.
The linked article is dumb, doesn't have any technical details, but has a stupid sensational headline.