2 ms·

> 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? Us

> 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.

rob_c 4y ago
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.
jeroenhd 4y ago
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.
- rollcat 4y ago
  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. [0]: https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2

rob_c 4y ago

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.

jeroenhd 4y ago

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.

rollcat 4y ago
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. [0]: https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2