mjg59: No, really, secure boot does add security

Matthew Garrett (

mjg59) wrote,
@ 2012-06-14 08:39 pm UTC

Entry tags:

No, really, secure boot does add security

Carla Schroder wrote a piece for linux.com on secure boot, which gives a reasonable overview of the technology and some of the concerns. It unfortunately then encourages everyone to ignore those legitimate concerns by making the trivially false claim that secure boot is just security theatre.

Security isn't some magic binary state where you're either secure or insecure and you can know which. Right now I'd consider my web server secure. If someone finds an exploitable bug in Apache then that would obviously no longer be the case. I could make it more secure by ensuring that Apache runs in a sufficiently isolated chroot that there's no easy mechanism for anyone to break out, which would be fine up until there's also a kernel exploit that allows someone to escalate their privileges enough to change their process root. So it's entirely possible that someone could right now be breaking into my system through bugs I don't even know exist. Am I secure? I don't know. Does that mean I should just disable all security functionality and have an open root shell bound to a well known port? No. Obviously.

Secure boot depends on the correctness of the implementation and the security of the signing key. If the implementation is flawed or if control of the signing key is lost then it stops providing security, and understanding that is important in order to decide how much trust you place in the technology. But much the same is true of any security technique. Kernel flaws make it possible for an unprivileged user to run with arbitrary privileges. Is user/admin separation security theatre? SSL certificate authorities have leaked keys. Is it security theatre for your bank to insist that you use SSL when logging in?

Secure boot doesn't instantly turn an insecure system into a secure one. It's one more technology that makes it more difficult for attackers to take control of your system. It will be broken and it will be fixed, just like almost any other security. If it's security theatre, so is your doorlock.

Why is this important? Because if you tell anyone that understands the technology that secure boot adds no security, they'll just assume that you're equally uninformed about everything else you're saying. It's a perfect excuse for them to just ignore discussion of market restrictions and user freedoms. We don't get anywhere by arguing against reality. Facts are important.

(Read 48 comments) - (Post a new comment)
(Flat) (Top-level comments only)

assumption of innocence

(Anonymous)
2012-06-15 01:58 pm UTC (link)

I'll readily admit that I have only a cursory knowledge about the inner workings of secure boot, but from my reading there is no mechanism for any OS to assert that it has booted securely. The only informative mechanism is an in-memory flag that can be trivially provided by a subversive boot element.

When I read the title of your post, I was hoping that you would clarify the method with which an OS can assert its secure-boot status, because as I see it, secure boot is mere sophistry: you start from a presumed-secure base, then erect big and inconvenient obstacles to try and maintain that assumption.

But how does the OS prove the base was secure to begin with?

(Reply to this) (Thread from start) (Parent) (Thread) (Hide 9 comments) (Show 9 comments)

Re: assumption of innocence

(Anonymous)
2012-06-15 03:56 pm UTC (link)

"When I read the title of your post, I was hoping that you would clarify the method with which an OS can assert its secure-boot status, because as I see it, secure boot is mere sophistry: you start from a presumed-secure base, then erect big and inconvenient obstacles to try and maintain that assumption."

Secure firmware is flashed at the factory and can only be re-flashed with signed updates. Obviously if the firmware is compromised it can just lie to the OS and say that the boot is secure when in fact is not.

(Reply to this) (Thread from start) (Parent) (Thread) (Hide 3 comments) (Show 3 comments)

	Re: assumption of innocence (Anonymous) 2012-06-15 06:14 pm UTC (link)
	Does the secure boot specification contain a (mandatory) hardware failsafe that prevents an unsigned firmware from being written by a compromised OS? (Reply to this) (Thread from start) (Parent) (Thread) (Hide 2 comments) (Show 2 comments)

	Re: assumption of innocence mjg59 2012-06-15 08:31 pm UTC (link)
	The spec doesn't, but all implementations do. (Reply to this) (Thread from start) (Parent) (Thread) (Hide 1 comment) (Show 1 comment)

	Re: assumption of innocence (Anonymous) 2012-06-19 12:41 pm UTC (link)
	Thanks, that's good to know (Reply to this) (Thread from start) (Parent)

	Re: assumption of innocence mjg59 2012-06-15 08:30 pm UTC (link)
	There's no way for the OS to prove the base was secure, just as there's no way for the OS to prove that the PAM stack hasn't been replaced. All security involves placing some degree of trust in the underlying components. (Reply to this) (Thread from start) (Parent) (Thread) (Hide 4 comments) (Show 4 comments)

Re: assumption of innocence

(Anonymous)
2012-06-19 12:59 pm UTC (link)

But that's not really true, as there is debsums and/or rpm -V. You don't need to trust the underlying components as long as you can observe them independently.

In the case of secure boot, that independent observation can't come from the machine itself, because by definition it cannot be trusted. But I wonder if LOM techniques combined with corporate network management wouldn't be able to provide verifiable security?

(Reply to this) (Thread from start) (Parent) (Thread) (Hide 3 comments) (Show 3 comments)

	Re: assumption of innocence mjg59 2012-06-19 02:34 pm UTC (link)
	How do you trust debsums or rpm if you can't trust that the kernel is accurately reporting the filesystem contents? (Reply to this) (Thread from start) (Parent) (Thread) (Hide 2 comments) (Show 2 comments)

	Re: assumption of innocence (Anonymous) 2012-06-21 02:03 pm UTC (link)
	My response wasn't about the kernel issue, I was referring to your assertion that there is "no way for the OS to prove that the PAM stack hasn't been replaced". But there is, since the OS can execute processes in parallel with the PAM stack (e.g. init, sulogin) which can independently observe it. (Reply to this) (Thread from start) (Parent) (Thread) (Hide 1 comment) (Show 1 comment)

	Re: assumption of innocence mjg59 2012-06-21 02:09 pm UTC (link)
	Of course, once someone's replaced the PAM stack, they've also had the ability to modify everything that could validate it. (Reply to this) (Thread from start) (Parent)

(Read 48 comments) - (Post a new comment)
(Flat) (Top-level comments only)