Signing ELF binaries [LWN.net]

By Jake Edge
January 16, 2013

As part of the effort to support UEFI secure boot on Linux, Matthew Garrett proposed a number of restrictions on kernel features so that signed kernels could not be used to circumvent secure boot. Many of those restrictions were fairly uncontroversial, but disabling kexec() was not one of them, so it was dropped in a later patch set. At the time, there was discussion of how to support kexec() in a secure boot world; Vivek Goyal recently posted an RFC patch set to start down that path.

The kexec() system call is used to replace the running kernel with a different program. It can be used to boot a new kernel without going through the BIOS or other firmware, which is exactly what gets it into trouble for secure boot. A running kernel that has been verified by the secure boot mechanism (and thus is trusted) could boot any unsigned, unverified kernel by way of kexec(). The concern is that it would be used to boot Windows in an insecure environment while making it believe it was running under secure boot—exactly what secure boot is meant to prevent. That, in turn, could lead to Linux bootloaders getting blacklisted, which would make it more difficult to boot Linux on hardware certified for Windows 8.

Goyal's patches add the ability to cryptographically sign ELF executables, then have the kernel verify those signatures. If the binary is signed and the signature verifies, it will be executed. While the patch does not yet implement this, the idea is that a signed binary could be given additional capabilities if it verifies—capabilities that would enable kexec(), for example. If the binary is unsigned, it will always be executed. Only if a signed binary fails to verify does it get blocked from execution.

The patches contain a signelf utility that puts a signature based on the private key argument into a .signature ELF section. The signature is calculated by hashing the contents of the PT_LOAD ELF segments, then cryptographically signing the result. It is based on the module signing code that was recently added to the kernel, but instead of just tacking the signature on at the end of the binary, it puts it into the .signature section.

Since any shared libraries used by an executable cannot be trusted (so far, at least, there is no mechanism to verify those libraries), only statically linked executables can be signed and verified. The patches do not stop binaries from using dlopen() directly, however, so Goyal said binaries that do so should not be signed. He is targeting the /sbin/kexec binary that is used to launch kdump, so that users can still get crash dumps, even in a secure-boot-enabled system, but there are other possible uses as well.

When the binfmt_elf loader in the kernel detects a binary with the .signature section, it locks the pages of the executable into memory and verifies the signature. Goyal is trying to avoid situations where the binary is modified after the verification has been done, which is why the executable is locked into memory. If the signature does not verify, the process is killed; unsigned binaries are simply executed as usual.

Beyond just adding the capability for kexec(), there are some other pieces of the puzzle that aren't addressed in the patches. The biggest is the need to disable ptrace() on signed binaries. Otherwise, the signed binary could be subverted in various ways—changing the binary passed to kexec(), for example. In addition, the "to do" list has some key and keyring related issues that need to be sorted out.

There is already a mechanism in the kernel to verify the signature of various kinds of files, though. The Integrity Measurement Architecture (IMA) appraisal extension that was added in Linux 3.7 does much of what Goyal needs, as was pointed out by IMA maintainer Mimi Zohar. While the integrity subsystem targets measuring and verifying the whole system, it already does most of the kinds of signature operations Goyal is looking to add. On the other hand, features like disabling ptrace(), locking the binary into memory, and setting capabilities based on signature verification are well beyond the scope of the integrity subsystem. Goyal is currently looking into using the integrity features and adding secure-boot-specific features on top.

Losing the ability to use kexec() on secure boot systems would be rather painful. While Garrett's patches do not actually make that change (because of the outcry from other kernel developers), any distribution that is trying to enable secure boot is likely to do so. Finding a way to support that use case, without unduly risking the blacklist wrath of Microsoft, would be good.

Index entries for this article
Kernel	Security/UEFI secure boot

to post comments

Signing ELF binaries

Posted Jan 17, 2013 8:41 UTC (Thu) by kugel (subscriber, #70540) [Link] (2 responses)

I'm probably overlooking something totally obvious, but...

how can kexec trick Windows into believing it's in secure boot environment (SBE) while it's not?

If Linux boots in SBE, then Windows is also in the SBE (Windows will verify this, no?). If Linux boots in non-SBE and kexecs Windows, then Windows verification fails and it knows it's in non-SBE.

Signing ELF binaries

Posted Jan 17, 2013 10:48 UTC (Thu) by keeperofdakeys (guest, #82635) [Link]

Secure boot works a bit differently to what you think. The purpose of secure boot is to check the cryptographic hash of a binary, and if it's not trusted, then it isn't executed. Beyond this, there are no other protections. If you only sign pieces of code that you trust, and these only execute (privileged) pieces of code that you trust, you can ensure you are protected. So a signed, malicious binary can emulate a SBE environment, then boot the SBE enabled Windows.

Signing ELF binaries

Posted Jan 17, 2013 12:42 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

What do you mean, "In the SBE"? Windows can only verify itself if everything that's executed before it is trusted. If you can (via kexec) end up executing a modified Windows kernel, you've violated that expectation.

Signing ELF binaries

Posted Jan 17, 2013 21:16 UTC (Thu) by jimparis (guest, #38647) [Link] (2 responses)

> The concern is that it would be used to boot Windows in an insecure environment while making it believe it was running under secure boot—exactly what secure boot is meant to prevent.

My understanding is that's not true; secure boot has nothing to do with any integrity checking that Windows might want to perform. Windows (the software) can't ask "was I securely booted?" because you can just virtualize it and lie. Instead, attestation is left up to things like TPM / TCG, which can't be virtualized because they hold secret keys.

Secure boot approaches from the other direction, in that you (the user) can trust that the hardware only booted software that was signed. If Linux can boot an unsigned Windows, Microsoft would view that as a breach of their security chain and react by revoking the keys that were used to boot Linux in the first place.

Signing ELF binaries

Posted Jan 18, 2013 6:31 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> If Linux can boot an unsigned Windows, Microsoft would view that as a breach of their security chain

I'm not sure that really works out in practice because there are all sorts of ways to get an OS up and running in an "insecure" manner, running in a VM or other contrived environment for example. This isn't about protecting against compromise in any arbitrary case, it's about a very specific case of booting the primary OS on bare metal. You could certainly "secure boot" a small core system, windows or linux or whatever, and use that to make a contrived environment for booting your arbitrarily compromised OS (linux or windows or whatever) and I think this case is out side the scope and threat model that Secure Boot is intended to address.

You can't win them all 8-)

Signing ELF binaries

Posted Jan 18, 2013 11:19 UTC (Fri) by etienne (guest, #25256) [Link]

> Secure boot approaches from the other direction, in that you (the user) can trust that the hardware only booted software that was signed.

I.e. that it is a lot more difficult to boot a patched version of Windows which "forget" to check if it is a legitimate install.

Playing a game that cannot be won?

Posted Jan 18, 2013 4:00 UTC (Fri) by proski (guest, #104) [Link] (14 responses)

It seems to me that some Linux developers have been tricked into playing a game they cannot win. Every time the "secure boot" is circumvented it would be considered a security issue in Linux. Secure boot is a whole new aspect of security, and Linux wasn't designed with it in mind. So there will be "security issues" all the time, and that would give Linux bad rap, especially among non-technical people.

I think Microsoft revoking a key for Linux bootloader would be a huge scandal and it would lead to anti-trust actions against the company. It would be better for Linux to refuse the security model demanded by Microsoft rather than try to implement it and fail.

Disclaimer: I'm not closely familiar with the situation around the "Secure boot".

Playing a game that cannot be won?

Posted Jan 18, 2013 6:25 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Secure Boot just allows you to boot into a known good state, it doesn't provide any attestation (you can't tell after you've booted whether you've done so "securely") and it only covers the firmware and bootloader, what you do in your OS kernel for security is up to you. There are many linux developers who are taking the opportunity to add integrity checking, now that it won't instantly be rendered pointless by trivially compromising the lower levels of the system stack (bootloader and firmware). Note too that there is no magic bullet preventing the running kernel from being comprimised, secure boot just makes it harder to modify the early boot files without being easily detected.

Playing a game that cannot be won?

Posted Jan 18, 2013 20:36 UTC (Fri) by nevets (subscriber, #11875) [Link] (12 responses)

As the developers are aggressively pushing the secure boot features, it seems to be a way to prove they are doing their "best effort" against a security compromise. We probably couldn't win against MS if we just abandoned their whole secure boot, and force the vendors to keep secure boot off. Although with Windows 8 not doing so hot, maybe we could.

Now if MS were to revoke a Linux key, then we can show the courts that we did everything and then some to not be a source of compromise. Even if Linux ends up being a source of a security breach, the fact that we did so much to avoid it, will at least demonstrate that it was not due to neglect on our part.

Playing the game automatically concedes defeat

Posted Jan 26, 2013 1:49 UTC (Sat) by cas (guest, #52554) [Link] (11 responses)

Now if MS were to revoke a Linux key, then we can show the courts that we did everything and then some to not be a source of compromise. Even if Linux ends up being a source of a security breach, the fact that we did so much to avoid it, will at least demonstrate that it was not due to neglect on our part.

Actually, it would work in exactly the opposite way - by attempting to implement Microsoft's secure boot and failing, they are legitimising Microsoft's demands and providing justification for Microsoft to revoke linux keys for failure to comply or for any reason at all.

i.e. by attempting to implement, they are undermining their best argument (in court and in the outside world), that Microsoft has no legal right to unilaterally grant itself the power to decide what is allowed to boot, and that their attempt to do so is an illegal abuse of a monopoly.

These attempts to appease Microsoft are short-sighted and we will all come to regret them bitterly - even if they succeed (unlikely), the absolute best we can hope for is centralised control over official bootable linux kernels. say goodbye to small and non-commercial distros, say goodbye to experimentation. and say goodbye to the right to run whatever the hell you want on your own hardware. And that's the best. The actual result is likely to be far worse.

Playing the game automatically concedes defeat

Posted Jan 26, 2013 5:40 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (10 responses)

"Actually, it would work in exactly the opposite way"

You have the background to provide a legal justification for that?

Playing the game automatically concedes defeat

Posted Jan 26, 2013 6:15 UTC (Sat) by cas (guest, #52554) [Link] (9 responses)

No, do i need a legal background to hold or express an opinion? Do you have one?

What I do have is a functioning memory and a reasonable ability to extrapolate from similar concepts.

By playing Microsoft's game you are implicitly accepting their terms and conditions, or as i said the first time around, legitimising Microsoft's *right* to terminate your boot key according to whatever rules they choose.

Actually, it's worse than that - to get a key signed by MS you have to *explicitly* accept their terms and conditions (BTW, do they have a clause saying they can unilaterally change them at any time?). It would be extremely unlikely for a court to invalidate such a consciously chosen and legal agreement.

Appeasement on the secureboot issue may be good, cheap, and convenient policy for RH and other corporate linux vendors. Not for anyone else.

Playing the game automatically concedes defeat

Posted Jan 26, 2013 6:24 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (8 responses)

"No, do i need a legal background to hold or express an opinion?"

No, but having some ability to actually support contentions like "By playing Microsoft's game you are implicitly accepting their terms and conditions" is pretty important if you want anyone to pay any attention to what you're saying.

"Do you have one?"

No, but I've spent a significant amount of time speaking to lawyers about Secure Boot over the past 18 months, which is more than you seem to have done.

Playing the game automatically concedes defeat

Posted Jan 26, 2013 6:36 UTC (Sat) by cas (guest, #52554) [Link] (7 responses)

Appeal to Authority is a very popular logical fallacy, and you manage to improve upon it by adding the marvellous twist of second-hand, indirect authority.

Well done!

BTW, I note that you didn't comment on my "to get a key signed by MS you have to *explicitly* accept their terms and conditions" paragraph. I take it you have no glib logical fallacy at hand to distract from that so settled on the Ignore It And It Might Go Away technique?

Playing the game automatically concedes defeat

Posted Jan 26, 2013 6:45 UTC (Sat) by raven667 (subscriber, #5198) [Link] (4 responses)

Actually knowing something about what you are talking about isn't a logical fallacy "appeal to authority", it's actually knowing something about what you are talking about.

Playing the game automatically concedes defeat

Posted Jan 26, 2013 8:29 UTC (Sat) by cas (guest, #52554) [Link] (3 responses)

Entirely true. Also irrelevant. mj59 doesn't have any more valid an opinion about legal matters than I do.

I expect that any lawyers he has spoken to about secureboot would have been Redhat's lawyers, and their angle on the problem would have been entirely on the topic of Redhat's corporate needs, and how to solve the problem for RH in the most efficiently pragmatic way possible.

Pragmatism doesn't always conflict with idealism but this is one case where it definitely does.

Playing the game automatically concedes defeat

Posted Jan 26, 2013 11:48 UTC (Sat) by paulj (subscriber, #341) [Link]

Also, short-term pragmatism can conflict with long-term pragmatism. Idealism may sometimes be long-term pragmatism.

Playing the game automatically concedes defeat

Posted Jan 27, 2013 16:18 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

Red Hat has not always acted only for its own purposes. Take the patent settling cases where Red Hat got all of FOSS a license for the patents in question. So they do have a record for going beyond the (typical) call of duty.

That said, it would be nice to have some clarification of what they think the fallout of Microsoft revoking a Linux key (both for "but h4x" and "because market share[holders]" scenarios) would likely be.

Playing the game automatically concedes defeat

Posted Jan 27, 2013 16:38 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

I can't speak for Red Hat, but the expected outcome of a revoked signature due to security issues is a staged update of new binaries followed by a blacklist update, with the only user-visible inconvenience being that old media will stop working. The expected outcome of a revoked signature due to any other issue is a series of lawsuits.

Playing the game automatically concedes defeat

Posted Jan 26, 2013 6:52 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (1 responses)

Of course, we should ignore informed discussion in favour of handwaving because the alternative might possibly be something that could be construed as falling under something in Wikipedia's List Of Logical Fallacies. Good point. Let's move on to arguing about whether heliocentrism is relevant in modern life, because how many of us have actually observed the Earth's motion directly?

"to get a key signed by MS you have to *explicitly* accept their terms and conditions"

Have you read those terms and conditions? Have you consulted a lawyer to determine precisely which rights you're giving up? Or are you just asserting that they're unreasonable without any justification at all?

Playing the game automatically concedes defeat

Posted Jan 26, 2013 8:18 UTC (Sat) by cas (guest, #52554) [Link]

How exciting, another transparent attempt to evade any actual consideration of the issue - far easier to attempt to arrograntly dismiss it with a wikipedia slur. Too bad, i'm not so easily distracted with irrelevance.

My point is that it is entirely unreasonable to have to beg Microsoft's permission to run anything. So unreasonable that the only reasonable response is to refuse to have anything to do with it.

By agreeing to *ANY* conditions, no matter how benign or light-weight they might be, you are conceding that Microsoft does indeed have a right to grant or deny such permission.

You mean well and have good intentions, but you are enabling Microsoft in their aim to be gatekeeper of what software is permitted to execute. Aside from the old adage about the road to hell, the trouble with your work is that it is short-sighted and short-term pragmatism (you have what appears to be a technical problem and want to solve it now) with no regard for the long-term consequences. One day you will realise exactly what you have enabled and come to bitterly regret it. Unfortunately, you won't be the only one to suffer the consequences.

Signing ELF binaries

Posted Jan 24, 2013 1:58 UTC (Thu) by kevinm (guest, #69913) [Link]

Why can't the kexec_load() system call just be extended with a new flag KEXEC_SIGNED, signifying the presence of a fifth argument which is an array of kexec_segment_signature structures.