Secure Boot Coming To SuSE Linux Servers

darthcamaro writes "UEFI Secure Boot is a problem that only desktop users need to worry about right? Well kinda/sorta/maybe not. SeSE today is releasing SUSE Linux Enterprise 11 SP3 which will include for the first time — support for UEFI Secure Boot. Apparently SUSE sees market demand for Secure Boot on servers too. Quoting Matthias Eckermann, Senior Product Manager at SUSE: 'Our market analysis shows that UEFI Secure Boot is a UEFI extension that does not only cover desktops, but might very well also be deployed and even required on server systems going forward.'"

Comments

SecureBoot is incomplete

[Junta]

SecureBoot is an incomplete strategy. It only allows for attestation of software vendor provided content. It does nothing for:
-custom executables
-configuration data and so on

Servers in particular need to be looking for a mechanism for the customer to measure and secure their own boot stuff. Constructing a good enough root kit out of valid signed secureboot content is going to be feasible unless you render the system overly limited.

It's theoretically possible to completely break SecureBoot but still advertise SecureBoot as intact. System will merrily load up a signed hypervisor and that signed hypervisor may in turn do whatever the hell it wants including boot the 'normal' OS as a guest with firmware that will tell the OS whatever the attacker feels like. If secureboot is disabled, you can have a rootkit that advertises it as enabled without issue.

Ultimately, it's a mitigation strategy with huge gaping holes that people presume are no longer a problem because they don't take the time to understand the nuances of such a strategy. I'm not accusing the designers of this misconception, but the general population's understanding of the benefits of SecureBoot has been very misguided (I have heard some claim that PXE being wide open is ok because secureboot would protect it, in one example of how badly misunderstood Secureboot is)

Re:SecureBoot is incomplete

[Junta]

My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust. It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc, which SecureBoot does nothing to really facilitate meaningful measurement. SecureBoot is ill equipped to facilitate most of that.

It complicates use of non-microsoft OSes and I think the value of the mitigation provided is greatly overestimated due to a name that suggests more assurance than one should reasonably assume.

Re:SecureBoot is incomplete

[Nerdfest]

what you are booting is signed by someone you trust

Or Microsoft.

Re:SecureBoot is incomplete

[KiloByte]

It complicates use of non-microsoft OSes

And that's the whole reason SecureBoot is getting pushed onto manufacturers.

Re:SecureBoot has no place as implemented

[0123456]

Secure boot does nothing to prevent the end user from being in control, and it does not require anything from Microsoft. If your vendor does not allow you to install your own keys, get a better vendor.

So first you say that Windows Boot doesn't prevent the end user from being in control, then you admit that it puts the vendor in control. Vendor lock-in is the whole point of Windows Boot.

Secure Boot ISN'T!

[kawabago]

Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.

Re:SecureBoot has no place as implemented

[Rockoon]

Unless the hardware manufacturer won't let you.

Isn't this argument essentially fear, doubt, and uncertainty?