mjg59 | Don't like Secure Boot? Don't buy a Chromebook.

Entry tags:

advogato,
fedora

Don't like Secure Boot? Don't buy a Chromebook.

(Edit: It's been suggested that the title of this could give the wrong impression. "Don't like Secure Boot? That's not a reason to buy a Chromebook" may have been better)

People are, unsurprisingly, upset that Microsoft have imposed UEFI Secure Boot on the x86 market. A situation in which one company gets to determine which software will boot on systems by default is obviously open to abuse. What's more surprising is that many of the people who are upset about this are completely fine with encouraging people to buy Chromebooks.

Out of the box, Chromebooks are even more locked down than Windows 8 machines. The Chromebook firmware validates the kernel, and the kernel verifies the filesystem. Want to run a version of Chrome you've built yourself? Denied. Thankfully, Google have provided a way around this - you can (depending on the machine) either flip a physical switch or perform a special keystroke in the firmware to disable the validation. Doing so deletes all your data in the process, in order to avoid the situation where a physically present attacker wants to steal your data or backdoor your system unnoticed, but after that it'll boot any OS you want. The downside is that you've lost the security that you previously had. If a remote attacker manages to replace your kernel with a backdoored one, the firmware will boot it anyway. Want the same level of security as the stock firmware? You can't. There's no way for you to install your own signing keys, and Google won't sign third party binaries. Chromebooks are either secure and running Google's software, or insecure and running your software.

Much like Chromebooks, Windows 8 certified systems are required to permit the user to disable Secure Boot. In contrast to Chromebooks, Windows 8 certified systems are required to permit the user to install their own keys. And, unlike Google, Microsoft will sign alternative operating systems. Windows 8 certified systems provide greater user freedom than Chromebooks.

Some people don't like Secure Boot because they don't trust Microsoft. If you trust Google more, then a Chromebook is a reasonable choice. But some people don't like Secure Boot because they see it as an attack on user freedom, and those people should be willing to criticise Google's stance. Unlike Microsoft, Chromebooks force the user to choose between security and freedom. Nobody should be forced to make that choice.

(Updated to add that some Chromebooks have a software interface for disabling validation)

Threaded | Top-Level Comments Only

The rationale for forcing uses to choose between security and freedom is because you can't provide both together.

One particular use case that is considered important to Chromebooks is: You should, as a user, feel comfortable and secure using one that you do not own. Perhaps it's a loaner Chromebook like Virgin America provided last year for people on their flights, or one provided by a hotel you're staying at (another pilot Google has run), or a public kiosk, etc.

A simple reboot of the device will show whether or not it is a trusted OS installed on it; this is why once the developer switch is toggled, the firmware will always give scary "OS IS UNTRUSTED!" warnings. All bets are off then: since the owner can manipulate the system, including disabling the verified filesystem, install key loggers, send your passwords to others, etc.

The middle-ground would be to semi-trust externally signed OS, for example permit additional signing keys to be added to the firmware so that it can verify that the non-Chrome OS kernel it's booting matches those keys to give the modding community some level of secure boot support.

You'd have to resolve the UI issue, making sure a user unaware of the concept of modding (my dad, for example) would be still aware that he shouldn't trust the device in its modded state. But also have some other level of UI for the modded device firmware not matching the additional keys, while also still supporting modders who flat out don't want to deal with secure boot.

Our firmware team, though I can't actually speak for them, support modding enough that this is probably more a case of getting people to agree on the right approach rather than flat-out denial. Though also you know how security people like to say No and get angry at you ;)

A simple reboot of the device will show whether or not it is a trusted OS installed on it

Which is obviously utter nonsense given that the lender has all the time necessary to install physical keyloggers.

And can replace the firmware chip or motherboard or .... as well. I don't think secure boot protects against physical attackers, just remote ones. That's what the chromium docs say too.

Benjamin Franklin: "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety"

Could you clarify the relevance?

"The rationale for forcing uses to choose between security and freedom is because you can't provide both together."
Freedom to use - you are correct. My employer, for example, doesn't give me complete freedom on their network. Neither does my bank.
Freedom to know - you are incorrect. It is imperative that how security functions is known so that the owners, operators and other parties can be sure it actually works and will actually do what it claimed.
So, for example, I know how SSH works. Doesn't do me a blind bit of good in accessing an SSH connection unless the owner has configured for me to use and given me the key/passphrase.

"You should, as a user, feel comfortable and secure using one that you do not own."
If one does *anything* sensitive on a device one does not own, one is a blithering idiot. Even a network one doesn't own is suspect (hence VPNs, HTTPS etc). I don't think SecureBoot solve this the problem of nasties on a device someone else owns in any shape or form.

I can't beleive that MG wrote that. What utter nonsense. OMFG. So what you are saying is that indiviuals should trust XYZ corporation who can steal your data but not the themselves. Oh man give your head a shake.

I presume it relates to the first line. It's easy to misread. e.g. the USA (to pick an example) should become an Orwellian super-state, and sacrifice freedom (the very thing it was founded on) at the altar of security.

I know that's how I read it the first time.

No? I'm saying that it should be possible for users to choose the set of software they want to trust, and there's no way to do that on a Chromebook.

Why was the user freedom (or whatever you want to call it) not written into the spec? Seems to be easy enough to do:
1. The user must be able to disable SecureBoot (but only by physical access)
2. The user must be able to install their own keys (but only by physical access)
3. UEFI must be passphrase protected, and the default must be changed by the user on first boot
4. It must be possible to do a factory reset (but only by physical access)
Seems to about cover everything. So why wasn't it in the spec? It's not like you buy a Ford and the manual says "If you don't use BP fuel, we will shoot your puppy".

Hmm...actually...I strongly suspect I know why it wasn't written into the spec. It was done to protect revenue, not to protect users.

It's not written in to the spec for fairly straightforward reasons - UEFI as a body is really only empowered to specify mechanisms, not how they're used. That's the power the hardware (and software) vendors give them.

MS gets the power to specify how the mechanism is used, because MS is in a market position to make that kind of demands and back them up with their marketing dollars. UEFI has no economic carrot, nor a stick, which is why UEFI wasn't (very) widely deployed on systems until MS said vendors had to to get Windows 8 marketing money.

It should also be mentioned that a Chromebook with disabled OS validation may be useful as a development machine, but it's certainly not something you would want to use on a day-to-day basis (or much less give someone without a technical background to use).

At least the new ones that don't have a physical switch require you to press ctrl-d on each boot (or wait a minute) while any other keystroke re-enables validation. You might imagine how inconvenient that can be.

Millions of people all over the planet are using computers every day without secure boot technology enabled, what are you saying about these machines?

And no doubt you've got some fancy technology up your sleeve that will allow computers to securely boot user-compiled kernels. Tell me you've got all the security issues worked out. Uh-huh.

It is possible to replace the keys in the Chromebook firmware and there is a script provided in Chrome OS that will do it at /usr/share/vboot/bin/make_dev_firmware.sh as well as more scripts in the verified boot source repository that will assist with generating new keys and signing kernel images.

The major inconvenience here is that the keys live in a read-only firmware region so you need to defeat the write protection first which involves opening the case. Of course devices are all slightly different in how they implement write protection -- some require removing a screw and others use a jumper -- and the specifics for each board are not documented well enough yet but that is something we can and will fix Real Soon Now.

Supporting a user-provided key in developer mode that would only boot user-signed kernels is something we hope to do for future devices, but it has not happened yet. It is certainly fair to complain that the process is rather painful right now.

It is also worth mentioning that the entire firmware stack is as open as possible so if someone is not satisfied with what is provided they can build their own. This is obviously only useful to a really small/brave set of people and, just as with replacing the keys, it means you will no longer be able to boot official Chrome OS images unless you were smart enough to back up the firmware first.

--Duncan Laurie

Matthew Garrett you have missed something.

Most chromebooks when unlocked have a mandatory boot order with no change options. This starts with the SD card. Big advantage of SD card it can be set read only.

Place validating loader on SD card then set it read only insert itand you are done. No other boot device will run on most of them.

So yes users could possibly set the software they want to trust on lots of models of unlocked chromebooks. If boot loader for the sd card exists to validate. Remember the sd card has to be switched to read only after its configured.

Read only SD card on motherboard for OS or OS's secuirty auditing bootloader would have been many times better than the UEFI idea. Simpler update as well.

oiaohm

You wrote "Chromebooks are either secure and running Google's software, or insecure and running your software."

That's a sentence that could easily be taken out of context to imply something very different from what I think you meant. That is, given that sentence alone one might think you are suggesting that Google's software provides security while "your software" provides insecurity. And I think your intended meaning relies on an implicit assumption that's exactly opposite.

In fact, I think you are talking about two different kinds of security here, both of which are desirable. And you are pointing out that in Google's system both cannot be obtained simultaneously. The first security is that of a "validated boot", (firmware validates that system to be booted been signed with an installed key). The second is an "obeys my bidding" sort of security, (I've seen the code, I've modified it according to my desires, it doesn't contain any anti-features like spying, etc.).

The way I understood your original sentence is: "Chromebooks are either secure [with "validated boot"] and running Google's software [insecure—doesn't "obey your bidding"], or insecure [no "validated boot"] and running your software [secure—"obeys your bidding"].

-Carl (cworth@cworth.org)

Isn't the Chromebook's firmware Coreboot (http://www.coreboot.org/Samsung_XE550C22-H02US), not UEFI? This is an important note, since one of the benefits of Coreboot (http://www.coreboot.org/Benefits) is that it is Free software. Ultimately, which Chromebook did you use?

It's free software, but you can't currently replace it without some degree of hardware modification.

I applaud Google for letting users at least disable the validation verses a company like Apple that does not let you disable the validation on their ARM devices (iPod Touch, iPhone, iPad, Apple TV, etc.). I am typing this from an ARM Chromebook, and I love it. It is the most secure consumer OS available today on the market, and it is very inexpensive at that. If you ever want to tweak, you can do that too! I think that this is unfair criticism of Google who are trying to allow for options by allowing the disabling of secured boot.

> Big advantage of SD card it can be set read only.

Unfortunately not, it's more of a suggestion. The switch doesn't actually do anything to prevent writes to the card.

While you are technically correct, the article and this comment are misleading. When you say "the modification of hardware", you are referring to "open the box, flip a switch or jumper."

Is this an attempt to justify the fact that you have been working to make secure boot workable for Linux? Or is it an attempt to criticise some developers you don't like who are working for Google?

Tell me one thing: in your history of using Linux, how many cases have you come across of a compromised kernel being used to boot a box?

Why are people suddenly all barking about secure boot? Has there been some massive security incident that nobody on earth knows about - except Microsoft and Google?

Sam Varghese

You assume that the software from Google and Micrsoft is secure. I wouldn't be surprised if they are both spying on your actions while you use the computer. Therefore, only the Chromebook with dev mode will actually allow me to install software I trust onto the system. Much better than the Microsoft tablet.

Isn't that against the GPL?

Is this an attempt to justify the fact that you have been working to make secure boot workable for Linux? Or is it an attempt to criticise some developers you don't like who are working for Google?

No? It's an attempt to dissuade people from blindly recommending Chromebooks as an alternative to Microsoft's imposed Secure Boot setup.

Tell me one thing: in your history of using Linux, how many cases have you come across of a compromised kernel being used to boot a box?

More than once. The use of kernel modules as persistent rootkits is hardly uncommon.

Why are people suddenly all barking about secure boot? Has there been some massive security incident that nobody on earth knows about - except Microsoft and Google?

Secure Boot would be impractical to implement on BIOS systems, so the timing's largely down to the availability of alternative firmware implementations for x86. Embedded devices have implemented equivalent technology for years.

Threaded | Top-Level Comments Only

Page 1 of 4

Don't like Secure Boot? Don't buy a Chromebook.

Rationale

Re: Rationale

Re: Rationale

Security VS Freedom

Re: Security VS Freedom

Re: Rationale

Utter nonsense

Re: Security VS Freedom

Re: Utter nonsense

Why's it not in the spec

Re: Why's it not in the spec

Disabled OS validation is also annoying

Re: Disabled OS validation is also annoying

no subject

Lot of chromebooks could be secured.

A clarification to avoid misreading

Coreboot

Re: Coreboot

Wow

Re: Lot of chromebooks could be secured.

Re: Coreboot

Red herring?

assumed security

Re: Coreboot

Re: Red herring?