User: Password:
Subscribe / Log in / New account

SUSE and Secure Boot: The Details (SUSE Blog)

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 13, 2012 17:17 UTC (Mon) by drag (subscriber, #31333)
In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by RogerOdle
Parent article: SUSE and Secure Boot: The Details (SUSE Blog)

> The problem with secure boot is that the implementation is entirely self serving to the vendors. It is not really intended to make the computer more reliable, it is intended to throw obstructions in the way of competition. In particular, Linux and Google/Android.

Well, it does actually kinda solves a problem... having a insecure boot.

Things like NT Kernel and LKM rootkits are a real problem. Bootloader malware is a real problem also.

Having a insecure boot means that it is trivial for any attack to gain the sort of control over a system that would render any sort of anti-virus, root kit detector script, kernel level defense, or any other sort of host-based intrusion detection software completely and utterly useless. No matter what the level of sophistication of the anti-malware software you may be running on your desktop or running your enterprise systems.

Unfortunately it is just one part of a 'total solution'. By itself it is vulnerable to different approaches.. so it's not really making things that much better. It is, however, a necessary part of securing a system during boot up. Without it you couldn't do it. It's just a part of a larger system.

I don't know what all else is needed. Probably a TPM-type chip on your system + signed kernel modules and such things.

Once we get those pieces sorted out then it opens up the possibility for host-based intrusion systems to not be almost totally worthless.

(Log in to post comments)

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 14, 2012 7:51 UTC (Tue) by marm (guest, #53705) [Link]

I think that it is a mistake to assume that UEFI secure boot will solve the problem.

Systems based on certification authorities are seldom secure. Especially when the authority has little motivation to check things carefully. SSL/TLS is a prominent example of that and there is no reason to believe that secure boot will be better.

I agree that having signed bootloaders and kernels is nice, but the control of what is trusted and what not should be solely in the hands of the owner of the machine, not in hands of a third party (and certainly not of a company which is well known for poor security).

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 14, 2012 10:09 UTC (Tue) by anselm (subscriber, #2796) [Link]

The nice thing about SSL/TLS is that many applications do not actually require the use of an external signing authority. You have everything you need to be your own CA, and that can in many cases be quite helpful.

In the same vein, if I was in charge of IT for a big(gish) organisation I would certainly take a look at UEFI Secure Boot with a view to using my own keys to sign stuff I want to run on my machines. The SUSE approach doesn't look too bad at first glance.

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 14, 2012 22:19 UTC (Tue) by marm (guest, #53705) [Link]

Yes, but you need to remove the Microsoft's key first.

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 14, 2012 12:38 UTC (Tue) by slashdot (guest, #22014) [Link]

Not really.

The malware can just put something in the "StartUp" folder or similar that exploits the kernel and then does whatever it would have done if it has infected the boot sector, including blocking or filtering updates to the OS and all security software, putting the OS in a VM, etc.

Secure boot is mostly useless unless the signed bootloaders and kernel either don't allow arbitrary applications to run outside a truly secure sandbox, or at least download and execute an update from the Internet before running such code (the update would include malware removal code, obviously).

The former would require a complete redesign of both Windows and Linux, while latter is still very tricky (you must use trusted drivers, and you can't use normal network configuration, or malware would simply configure a bogus static IP address, making the update fail, and then fix it later when it owns the machine).

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 14, 2012 21:34 UTC (Tue) by Wol (guest, #4433) [Link]

But you solve those problems by booting from CD, and scanning the hard disk for rootkits.

The problem with UEFI is it provides a large attack surface that can be compromised before any sort of external trusted media can load. A minimal bios, booting a CD, is guaranteed to give you a system as secure as your CD.

A UEFI system, if compromised, means your system is unrecoverable.


SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 14, 2012 22:28 UTC (Tue) by raven667 (subscriber, #5198) [Link]

A BIOS booting a CD is not guaranteed to give you a secure system as there is nothing protecting the BIOS itself. The BIOS can be modified with malware that you'd be unable to detect with anything running afterwards. UEFI Secure Boot both protects the firmware from modifications unauthorized by the user and provides a base to check the bootloader, kernel, etc. so that you can have a small beachhead of known good code before any malware can load. This allows you to self-host the kind of rootkit scanning that you are trying to use a CD for.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds