Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 18:50 UTC (Mon) by raven667 (subscriber, #5198)
In reply to: Garrett: Secure Boot and Restricted Boot by paulj
Parent article: Garrett: Secure Boot and Restricted Boot

> However, fitting a lock to my front door would *not* be the best prioritisation of my resources if the windows and other external entrances still hadn't had window frames & glass, & doors fitted

I have two points here, 1) The development labor happens in parallel and independently so there is no prioritization implied, work on Secure Boot doesn't take away work from other security technologies, multiple things can be worked on at once. 2) There is already quite a depth of available security technologies from permissions to SELinux to various sandboxing and namespace technologies to whole VMs so it is not fair to say that other avenues of attack aren't covered in some way. Secure Boot is a fall back position to help recover a system when those other technologies have failed but those other technologies are on the front line of defense and are being worked on all the time.

> Because it is equally possible to write an exploit for early, privileged userspace, and use a general runtime exploit to install it. "Secure Boot" buys you *nothing* in this context.

This really depends on how far you can extend your prevention of unauthorized remote modification. At some point you have to allow arbitrary code to run but the farther you can push that out the more base OS tools you can fall back on to reliably clean out the later layers, including anti-malware software.

> However, "Secure Boot" CAN prevent the average *OWNER* of the machine from using the machine - once the "restricted boot" bit is set by some other party (e.g. the hardware vendor). In this context, the "Secure Boot" technology does indeed generally work. It makes "Restricted Boot" work.

Secure Boot _can't_ be used to prevent the owner of the machine from doing what they like because that's not how the policy works, so that's not how the technology works. Fighting against a policy change to enable boot locking, which is what the article is about and where you share common ground, doesn't require one to be against boot time signature verification in any form just because it uses the same technology.

You can join on the common ground of being generally against boot locking if you are willing to accept that some people do actually like the idea of user-controlled boot time signature verification.

I see this whole debate, of being generally anti-SecureBoot, as being the same arguments as being anti-encryption. The anti-encryption stance is that "bad guys" might use unbreakable encryption to "bad things" so therefore no one should be allowed to have encryption without allowing that the "good guys" use of encryption outweighs the potential for bad use.

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 20:19 UTC (Mon) by paulj (subscriber, #341) [Link] (27 responses)

On the labour point: this only makes sense if:

a) The overall goal is achievable

b) The sub-task delivers some benefit of its own, regardless of whether or not the overall goal is achievable.

It is highly doubtful that the overall goal is achievable, at least not with the way the software that compromises a Linux system is developed today. Indeed, it's highly uncertain the overall goal is achievable at all.

So then the question is about b, what does "Secure Boot" achieve, if it is booting software that is swiss cheese to any half-decent exploit writer (but not to ordinary users, necessarily)? If nothing, then it is (at best) labour wasted. At worst, it is deploying a system that will only secure systems against normal users, but not capable crackers (or those with access to the tools of such).

What exactly will "Secure Boot" achieve, in the context of a full system? What threats will it guard against?

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 21:15 UTC (Mon) by raven667 (subscriber, #5198) [Link] (26 responses)

> What exactly will "Secure Boot" achieve, in the context of a full system? What threats will it guard against?

It gives you the benefits of booting off read-only media but with the ability to update software without changing physical media. It provides a small limit on the ways an attacker can hide their activity by modifying your system and gives you some control over the software that you run, how much control you have is up to how much control you implement.

>At worst, it is deploying a system that will only secure systems against normal users, but not capable crackers (or those with access to the tools of such).
> If nothing, then it is (at best) labour wasted.

Agreed there is no point in wasting a lot of time on fancy control schemes when malware writers have clearly demonstrated the ability to just bury their malware in deeper layers of the systems if they have to. That's one reason why there hasn't been a lot of work on anti-malware tools on Linux although there has been a lot of work on sandboxing and containment technologies.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 5:23 UTC (Tue) by paulj (subscriber, #341) [Link] (22 responses)

I don't understand the read-only media / update benefit? Secure Boot doesn't give you read-only media (see previous discussions about using existing data to exploit the "Secure Boot"ed software). You would need to heavily restrict the ability of the "Secure" software to load or read any external data, as well as restrict the ability of any user to modify any of the existing data. At that point, you no longer have a general purpose system.

The attackers that are controlled will be the unsophisticated ones, the ones who can't write an exploit to begin with, and who don't have access to the ones already written. I.e. users who aren't generally in the habit of subverting boxes anyway, aren't aware of / in the security/cracking scene. I.e. normal users.

What is your view on how the benefits to user-owners of "Secure Boot" weigh up against the risks that others use this technology to "Secure" the machine against the user-owner? E.g. those who control the software/machine before it is given to the user-owner, such as the vendor? Clearly you believe this system can be used to secure a machine to at least some extent (and I agree). So why not against the user-owner? All it takes is for the vendor to /remove/ one feature. That is 1 bit of information's difference to go from "Secure Boot" to "Restricted Boot". Why will this not happen?

Can you at least acknowledge this is a risk?

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 16:31 UTC (Tue) by raven667 (subscriber, #5198) [Link] (15 responses)

> I don't understand the read-only media / update benefit?

I was just trying to say that the security properties it is trying to achieve are analogous to the properties of booting from read-only media, but with the ability to install updates even when running on Satan's Machine.

> You would need to heavily restrict the ability of the "Secure" software to load or read any external data, as well as restrict the ability of any user to modify any of the existing data. At that point, you no longer have a general purpose system.

There is definitely the possibility of implementation bugs that trigger on the data which is loaded from early boot or by the OS. Filesystem bugs have been demonstrated in practice on USB sticks and are very nasty indeed. The difference is that you still have the ability to reliably patch the system, the fix can't be modified in transit. I should also point out that there is a limited attack surface that can be modified remotely affecting early boot so a greater benefit from auditing the critical code paths that touch untrusted data.

> What is your view on how the benefits to user-owners of "Secure Boot" weigh up against the risks that others use this technology to "Secure" the machine against the user-owner?

I think it has a small but clearly tangible benefit while the risk is nebulous and in-tangible. There is a large installed base of systems such as Win7, Linux, *BSD which don't support a boot-locked, Tivoized system so I don't see the existing hardware getting firmware updates which change this behavior and break those installed systems. All of this is happening out in the open so it is no mystery if, in the future, a vendor tries to ship a boot-locked system or if MS tries to boot lock the next generation of hardware, there will be plenty of warning. That is something we all agree can and should be fought.

> Why will this not happen?

Even in the phone market where boot locking is very common many vendors don't boot lock their devices and some (Google Nexus) explicitly call out the openness as a feature. I don't think it a likely outcome that the general purpose PC market becomes _more_ restrictive and locked down than the smart phone market. If MS and the hardware vendors wanted the machines to be boot locked then there would probably just be different SKUs for Win8 bootlocked machines and general purpose machines, like you see in the smart phone industry, but that's not what happened.

> Can you at least acknowledge this is a risk?

Is there a reasonable risk that some vendor at some time will try an sell a boot locked x86 PC, sure that's possible, don't buy those machines and expect to run Linux on them, but is there a large risk that the vast majority of the market in the future, or the machines already shipped, become boot locked, I don't think that's a foreseeable outcome. I think it would be expensive and difficult to get hardware vendors and customers on that bandwagon for very little benefit as MS already gets a cut of most machine sales. Secure Boot can't even tell if you paid for the bits, only that they are signed, so it's useless against piracy.

Thanks for the lively and civil debate, I think we both understand each other's ideas now and we agree on the core argument that boot locking is bad but I don't see the value in rejecting any boot verification, even an open, user-controlled one, just because it works like boot locking.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 16:57 UTC (Tue) by paulj (subscriber, #341) [Link] (12 responses)

You can't patch a compromised system back to non-compromised status. The rootkit can just lie to you that it has installed the update. It can lie to you about the kernel version in boots there-after.

Once your box is compromised, you're hosed.

You're deluding yourself that Secure Boot gives you the equivalent of "read-only media, except to the software I trust", because the base OS is simply *way* too large to trust to be secure against exploits. At least, for a general purpose, generally programmable OS.

What you /really/ want is a "Secure Layer" between the software you don't trust (i.e. pretty much all software), and the software you have no choice but to trust (i.e. the base OS, which is on your side, but is too large and has to do too much low-level, fiddly work to be securable). Secure Boot doesn't give you that layer. The claimed security benefits are illusory.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 18:44 UTC (Tue) by raven667 (subscriber, #5198) [Link] (11 responses)

> You can't patch a compromised system back to non-compromised status. The rootkit can just lie to you that it has installed the update. It can lie to you about the kernel version in boots there-after.

It can fail to install the update but not hide that fact, it can't modify the boot procedure so you'd still be visibly booting the old kernel. If you can push update code into the verified part of the boot process, from the systemd recovery console maybe, then you might be able to update before the malware could even block it. You can certainly do that for the UEFI firmware itself which has a network stack and drivers that are available before your system could be re-exploited by malware.

Of course, as I mentioned in the other thread, an exploit through unvalidated data reads such as configs, variables or filesystem mounts could subvert your checking before it gets off the ground but that's true regardless of the security precautions, your SELinux or file permissions aren't much good after malicious code is running around in the kernel.

> What you /really/ want is a "Secure Layer" between the software you don't trust (i.e. pretty much all software), and the software you have no choice but to trust (i.e. the base OS, which is on your side, but is too large and has to do too much low-level, fiddly work to be securable). Secure Boot doesn't give you that layer. The claimed security benefits are illusory.

I think that's called a hypervisor 8-) Virtualizing x86 and using the extra layer of memory protection built into modern CPU/IOMMUs has a much lower vulnerability surface area than the userspace/kernelspace and has shown to be strong in practice given the low number of VM exploits compared to the number of kernel exploits. The fact that Secure Boot isn't a hypervisor doesn't detract or affect what it does try to do.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 18:55 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

> It can fail to install the update but not hide that fact, it can't modify the boot procedure so you'd still be visibly booting the old kernel.

Sure it could

the label that is shown to the user has no connection with the binary blob that gets loaded, it's only convention that keeps them matching.

Once the system boots the old kernel and loads the exploit, it can then lie about what version it is.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 19:08 UTC (Tue) by raven667 (subscriber, #5198) [Link] (9 responses)

I was thinking more about the message which are printed as the kernel boots up, the first of which is the version information.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:00 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

The messages which modern distros have hidden away behind user friendly splash screens?

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:03 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

Oh, and under the control of the subverted software :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:34 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

Yes, the messages are generally hidden behind splash screens but are still accessible (the display office is in a filing cabinet in a disused lavatory in the basement with a sign on the door "Beware of Leopard" 8-) Aside from the possibility of an exploit of the firmware or kernel from stored config or filesystem metadata the kernel can't be subverted at the time those messages are printed. A syslog which sends the logs remotely or which signs them so the can't be removed/modified on disk, like rsyslog or the systemd journal, could also prevent the malware from being hidden even if it tries to retroactively edit the dmesg buffer after the malware starts, presuming that the system software is started before the malware is allowed to.

The world is not a perfect place but it seems you still have more and better options with boot time validation than without any. Heck, the threat of failing a validation check should keep most malware away of the difficult to exploit protected parts and focused on the easier unprotected parts later in the boot process where it is simpler to deal with.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:52 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

You're assuming syslog gets to run before the system is re-subverted, alternatively, you're assuming syslog isn't subvertable through anything it reads. I'll grant those assumptions, while not rock-solid, aren't terribly far-fetched.

You still have a *massive* assumption: that the new kernel isn't subvertable.

While, perhaps, the subversion that compromised your box on the previous boot may be fixed, that doesn't mean there aren't still a number of other extant holes still unpatched, that only the exploit writers know about.

You're assuming the exploit has only laid 1 trap to ensnare the next boot.

Back to syslog: How many remotely syslog? Of those, how many would notice a discrepancy between the remotely logged version numbers and the local uname -a? Hell, how many would notice if the exploit didn't bother faking the version? :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 21:15 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

> You still have a *massive* assumption: that the new kernel isn't subvertable.

I don't think that is assumed, I'd have had to make the claim that any and all kernel images are perfect and totally secure for you to make that claim, I didn't and that's not a reasonable claim.

> Of those, how many would notice a discrepancy between the remotely logged version numbers and the local uname -a? Hell, how many would notice if the exploit didn't bother faking the version? :)

Damn few, but once exploits in the wild start using that technique it becomes burned, some people will start putting automated checks in their logging systems and the technique will stop working. You see that happen with exploits, once they start circulating in the wild the vendor patches the vulnerability and it becomes less and less effective so that the cycle starts anew.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 6:29 UTC (Wed) by paulj (subscriber, #341) [Link]

Still though, you're putting your faith in a security technology whose effectiveness depends on an arms race where the "bad" guys are routinely way ahead. We simply do not know how to make software secure, and so there's no way we can make a large base OS secure. You're *will* regularly lose, if/when you're attacked.

To have any hope of winning the arms race, your faith must go into software that both a) is minimal in size b) is minimal in the services it presents to software that uses it c) and limits the scope of software using it. Userspace sand-boxing and VMs basically. The Android user-space is the state-of-the-art in the real-world, widely-deployed system space when it comes to security and isolation of code, I think. And note that that security model does NOT rely on "Secure Boot".

That's not OS hypervisors, note, because if you're simply running the same OS in the hypervisor you still have the same problem in your virtualised OS. You have a more secure OS underneath to do integrity checks from, I'd agree, but it does not give you any means to have any additional trust in the software you're using at runtime. You still are just as prone to runtime subversion because you still have no isolation/sandboxing between the code & data you don't trust and the rest of the software. Also, things like the Qemu hardware emulation (which seem to be used a lot elsewhere) can have relatively complex interfaces, and they weren't necessarily written in a "security first" way. There have been a number of exploits in this code over the years.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:22 UTC (Tue) by apoelstra (subscriber, #75205) [Link] (2 responses)

The messages which modern distros have hidden away behind user friendly splash screens?

Right now, without secure boot, it wouldn't help anything to display version information on boot because running 'uname -a' on the booted system would have the same effect. In a secure boot world if you've got a way to display a version and cryptographically prove that it is not a lie, it would be used.

Probably there would be a magic key (escape or F1 or something) to make the pretty boot screen go away. In fact, I think this is the case now.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:40 UTC (Tue) by paulj (subscriber, #341) [Link]

The uname -a version info the user might query would, by then, be with the kernel subverted again during (early?) boot.

Kernel info pre-boot, or kernel init might be harder to change with Secure Boot, but that doesn't get shown anymore by default. Fedora doesn't even mention version info in the default bootloader UI anymore.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 21:25 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> Probably there would be a magic key (escape or F1 or something) to make the pretty boot screen go away. In fact, I think this is the case now.

Escape will toggle Plymouth. Since it's on a TTY, pretty much any arrow or function key will generate '^[', so they all work :P .

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 10:16 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Oh, and yes, it has been a good debate. Thanks :). Hope some of my more terse posts didn't come over as too abrasive!

Re the risks and our outlook. I do understand that some phones aren't locked down, and this is a selling point in some segments. I can understand why you see this as progressive and hopeful. However, I think that's a short-term view of things.

Look at the long-term of computing. Over my lifetime, computers have become ever more closed and user-hostile. When I was very young, all computers had full programming information publically available, from peripheral hardware, to the CPU, to the software environment. Often these were supplied with the computer by default. Some computers even came with full schematics for the board and/or CPU, even the entire system. As time progressed, the programming information available became more limited. Vendors tried to restrict the information even more. Most systems today, even ostensibly "open" ones, tend to have many components that are not documented. Sometimes even CPU software programming interfaces are kept hidden. Further, vendors have even tried to control what software can be run at all, using a variety of schemes.

The phones you speak of that are not locked are still, from my perspective, extraordinarily closed systems. They often contain non-publically-documented CPUs and DSPs. We're in the position where a computer that is touted as being the BBC micro for this era, the "open" hackable computer for today's youth, the raspberry Pi, runs the "open" software only under the control of another, undocumented CPU that requires a proprietary blob to boot it.

From my perspective, "Secure Boot" - which we're agreed is "Restricted Boot" minus 1 bit of information (or policy as someone else put it), with that bit under control of the vendor - is another step down this path of ever more locked-down and inaccessible computing.

Your perspective clearly is more optimistic than mine though. ;)

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 12:03 UTC (Wed) by paulj (subscriber, #341) [Link]

And yeah, I'm bunching together a number of issues here under "inaccessible" computing. :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 19:56 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (5 responses)

> At that point, you no longer have a general purpose system.

Some places might want to supply devices to others and ensure that it is indeed *not* a general purpose system for a legitimate reason. The user is not necessarily the owner in all cases (e.g., schools lending students laptops, employers, etc.). I can imagine schools wanting to make sure that no student can overwrite required software on the machine (possible excuses) and for IT support savings. This is "Restricted Boot" as far as the physical user of the machine is concerned, but "Secure Boot" from the actual owner's point of view. As far as vendors doing "Restricted Boot", yes, that's not good. However, *owners* being able to enforce "Restricted Boot" is not necessarily a bad thing.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 6:43 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

That's one legitimate use-case, agreed. With that in mind is why I wrote "user-owner" in some previous comments. :)

Personally, I'm happy to forego this use-case. I don't think the non-owner-user should necessarily be limited from using the device either. Further, generally it'd be better to keep restrict sensitive software to stay on owner-controlled servers as much as possible, rather than rely on "Restricted Boot", from a security perspective. When the device is returned, the owner can wipe and re-install.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 14:08 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (3 responses)

> When the device is returned, the owner can wipe and re-install.

How do you know that you didn't just install to some malicious hypervisor? That's what Secure Boot helps with. With a blue pill virus, you have to wipe BIOS to be sure you are running what you installed. And if the user had full access, that's certainly a possibility.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 20:30 UTC (Wed) by paulj (subscriber, #341) [Link]

Yes, "Secure Boot" would make "blue pill" harder, and provide a window during which to be able to detect OS subversion. However, you don't need "Secure Boot" to wipe & re-install - firmware usually provides a way to do this independent of any existing media.

If you say the firmware could be exploited then "Secure Boot" might not help either, if there is any unsigned, modifiable data that is parsed by the firmware. The firmware then may be as open to re-exploitation as the base OS.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 20:33 UTC (Wed) by paulj (subscriber, #341) [Link]

Oh, the Linux foundation shim loader should make blue pill attacks viable, even with "Secure Boot". So we'll see how long it stays signed and useable...

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 21:36 UTC (Wed) by PaXTeam (guest, #24616) [Link]

> How do you know that you didn't just install to some malicious hypervisor?

hypervisors are trivial to detect, no need for SB.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 5:26 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Oh, on sand-boxing. Fully agreed with such technologies. These seem to be the best way we have to secure our software - by limiting and controlling the environment it is run on.

However, clearly, this does NOT require that the main OS environment be the one that is restricted, limited, sand-boxed, etc.. through things like Secure Boot.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 15:24 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

I'm not sure I'd use the words restriction, limitation or sand-box, as it can't prevent you from using the machine in any way you want, it just defines a signature checking and validation like Tripwire but with a way to update the database securely and a policy to not load files that haven't come through the owner's defined process.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 15:51 UTC (Tue) by paulj (subscriber, #341) [Link]

The Secure Boot code, and the signing infrastructure brought in for Secure Boot can become Restricted Boot, if some platform flips the equivalent of a bit of information (see, e.g., the MS Surface ARM "Secure Boot", or future platforms), do you agree on that?

If that abstract bit is flipped, it will be the "Secure Boot" code that stops you booting your own software, and restricts you to approved software. (Unless you have the expertise handy to the exploit the software - I don't).

And still I havn't seen any convincing explaination for how this code helps protect me against those who /do/ exploit software regularly, for fun & profit.