Security

Fedora reexamines "trusted boot"

When we looked in on Fedora's decision on enabling "trusted boot" a little over a year ago, the consensus seemed to be that adding a feature that depended on a closed-source binary firmware blob ran counter to the distribution's goals. Since then, that blob is in the process of being added into the BIOS of various systems—though it remains closed—and the "tboot" (trusted boot hypervisor) package has been added to Fedora. Those changes might make it more attractive for Fedora to provide a way for users to enable it at install time. But there is still resistance to adding the feature, and it didn't make the cut for Fedora 16. It seems likely to come up again for Fedora 17 or beyond, so it may well make its way into the distribution sooner or later.

Trusted boot is a way to use the Trusted Platform Module (TPM) hardware that comes in many systems to only boot signed binaries. The fear is that it will enable hardware vendors to lock down their systems—by requiring binaries signed by their keys in order to boot—but it could also be used to protect against various kinds of malware. As with any hardware-based integrity scheme, it all depends on who holds the keys.

Matthew Garrett opened the discussion on fedora-devel, pointing to a proposed feature on the Fedora wiki. That wiki page is fairly thin on details, which is one of the things that sunk the proposal this time, but it essentially proposes changing the anaconda installer to allow users to choose trusted boot and to provide a way to change the GRUB configuration to support it.

One of the first questions was about the benefit of the feature to Fedora. Camilo Mesias asked about the use cases for trusted boot. Daniel Walsh listed a number of possibilities:

Several of those use cases rely on the "remote attestation" feature of trusted boot, which means that a suitably configured system that has the "proper" keys stored in the TPM can provide a signed cryptographic hash corresponding to the kernel in use. There was some confusion in the thread about what remote attestation means, but, beyond that, there are concerns that it could be used to thwart users installing their own kernel, even on free software OSes. As Gregory Maxwell put it:

A bigger problem might be that services start requiring some proprietary OS, rather than a particular Fedora kernel. That would, of course, suit the proprietary OS vendors just fine. But that could happen regardless of what Fedora does. If requiring a Fedora kernel is important, services can require that only approved kernels be used and require that users enable and configure trusted boot in order to access them. The more likely outcome under that scenario would leave Fedora (and other Linux distributions) out in the cold, of course.

While the closed-source nature of the SINIT blob (aka SINIT AC), which is the code that does the low-level integrity checking, worries some, Intel is evidently adamant that the code remains closed. From a practical standpoint, having the code wouldn't do much for users, as Miloslav Trmač points out:

As was noted in the thread, we are already largely at the mercy of the hardware and BIOS vendors with respect to the code that runs on our systems. The relatively recent System Management Mode (SMM) additions to the BIOS are just one example. As Adam Williamson put it:

But, the presence of Intel signing keys stored in the TPM, which is required to verify the SINIT blob, may lead to some worrisome restrictions. Björn Persson points out that there are alternative, free software BIOS implementations (e.g. Coreboot), but that it may be impossible to replace SINIT:

Aside from the technical issues, and concerns, the actual feature request on the wiki didn't provide a whole lot of information about how the feature would be used, and how it would be integrated into the Fedora install and boot processes. What facilities would be present for remote attestation, how they could be disabled by users, and what happens when a user tries to boot an "untrusted" kernel are all left up in the air in the feature proposal. It also didn't provide much in the way of justification for why trusted boot would be useful to Fedora users. It is clear to some that it could be useful, if users could create and install their own keys, but the wiki page didn't really make that clear. That led to several requests for more information to be added to the feature request.

The Fedora Engineering Steering Committee (FESCo) took up the request at its June 27 meeting. The discussion in the IRC log of the meeting paralleled that of the mailing list to some extent. The FESCo members seemed a bit puzzled by what exactly was being proposed—and why it would be useful. As Kevin Fenzi (aka nirik) said: "I think there's cool things we could use this for, but 'enable it now so we can do ~wave hands~ later' seems non ideal. Why not set it up to do something our users care about and _then_ enable it."

There was also some discussion of which pieces of Fedora needed changing (anaconda and grubby being two obvious places that might require modification). But the overall sense was that there just wasn't enough meat in the proposal to add it as a Fedora feature. Fenzi is optimistic that it could be done right for Fedora users, but it needs to be fleshed out more:

So FESCo decided to decline the feature for Fedora 16, but agreed that interested parties should continue working on it for possible inclusion down the road. Any work that is done in anaconda, grubby, or elsewhere will have to be negotiated between the trusted boot proponents and the other projects, as there is no FESCo mandate for the feature. It would not be surprising to see this feature come up again in six months or a year.

The TPM and "trusted computing" (aka "treacherous computing") evoke strong reactions. While it is clear that they can be used in ways that essentially lock users out of their own hardware, they could also be used in ways that allow users to ensure the integrity of the code running on those same systems. Like many technologies, trusted boot can be used for good or ill.

If Fedora can provide ways for its users to take advantage of this technology, without being taken advantage of, it will definitely be something that some security-conscious users will benefit from. Intel's secrecy with regard to the SINIT blob is somewhat troubling, but doesn't change the closed-source BIOS problem all that much really. A bigger problem for Fedora down the road may be trying to support users who enable the feature but run into problems getting their Fedora (or custom-built) kernels to boot. But, that's a problem for another day.

Comments (33 posted)

Brief items

Security quotes of the week

Comments (5 posted)

New vulnerabilities

asterisk: denial of service

Comments (none posted)

curl: exposed client credentials

Comments (none posted)

gdk-pixbuf2: excessive memory use

Comments (none posted)

git-web: cross-site scripting

Comments (none posted)

kernel: privilege escalation

Comments (none posted)

libgnomesu: privilege escalation

Comments (none posted)

libgssglue: privilege escalation

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>