Tamper-Evident Boot with Heads

Kyle Rankin — Thu, 31 Jan 2019 14:08:08 +0000

Learn about how the cutting-edge, free software Heads project detects BIOS and kernel tampering, all with keys under your control.

Disclaimer: I work for Purism, and my experience with Heads began as part of supporting it on Purism's hardware. As a technical writer, I personally find ads that mask themselves as articles in technical publications disingenuous, and this article in no way is intended to be an advertisement for my employer. However, in writing this deep dive piece, I found that mentioning Purism was unavoidable in some places without leaving out important information about Heads—in particular, the list of overall supported hardware and an explanation of Heads' HOTP alternative to TOTP authentication, because it requires a specific piece Purism hardware.

Some of the earliest computer viruses attacked the boot sector—that bit of code at the beginning of the hard drive in the Master Boot Record that allowed you to boot into your operating system. The reasons for this have to do with stealth and persistence. Viruses on the filesystem itself would be erased if users re-installed their operating systems, but if they didn't erase the boot sector as part of the re-install process, boot sector viruses could stick around and re-infect the operating system.

Antivirus software vendors ultimately added the ability to scan the boot sector for known viruses, so the problem was solved, right? Unfortunately, as computers, operating systems and BIOSes became more sophisticated, so did the boot-sector attacks. Modern attacks take over before the OS is launched and infect the OS itself, so when you try to search for the attack through the OS, the OS tells you everything is okay.

That's not to say modern defenses to this type of attack don't exist. Most modern approaches involve proprietary software that locks down the system so that it can boot only code that's signed by a vendor (typically Microsoft, Apple, Google or one of their approved third-party vendors). The downside, besides the proprietary nature of this defense, is that you are beholden to the vendor to bless whatever code you want to run, or else you have to disable this security feature completely (if you can).

Fortunately, an alternative exists that is not only free software, but that also takes a completely different approach to boot security by alerting you to tampering instead of blocking untrusted code. This approach, Heads, can detect tampering not only in the BIOS itself but also in all of your important boot files in the /boot directory, including the kernel, initrd and even your grub config. The result is a trusted boot environment with keys fully under your own control.

In this article, I describe some of the existing boot security approaches in more detail, along with some of their limitations, and then I describe how Heads works, and how to build and install it on your own system.

Go to Full Article

Good Lockdown vs. Bad

Zack Brown — Wed, 08 Aug 2018 12:00:00 +0000

by Zack Brown

There's an ongoing series of skirmishes between corporations who want to sell products that users don't fully control and the kernel developers who want users to be the highest authority. Sometimes these skirmishes manifest in the form of security patches intended to lock down the kernel. Do they lock down the kernel against outside attackers? Or do they lock down the kernel against change from anyone at all, including the user who owns the device?

David Howells recently pushed a patch out of the linux-next, submitting it for inclusion in the main source tree. As he put it, the patch "adds kernel lockdown support for EFI secure boot". And a man page included in the patch said:

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

The patch gave birth to an odd debate, but a familiar one by now. Matthew Garrett, ultimately the main proponent of the patch, kept defending it on technical grounds that Linus Torvalds felt were meaningless and dishonest, hiding a secret agenda that included helping companies like Microsoft lock users out of making changes to their own systems.

Andy Lutomirski was another critic of Matthew's defense of the patch. The debate circled around and around, with Linus and Andy trying to get Matthew to admit the true motivation they believed he had and Matthew attempting to give solid reasons why the patch should go into the kernel. Things got ugly.

James Morris initially accepted the patch, planning to send it up to Linus for inclusion, and Andy reviewed the code. Among his comments, Andy said the goal of the patch was not clearly stated. He said for the purpose of his code review he would assume the goal was to prevent the root user from either reading kernel memory or intentionally corrupting the kernel.

But, he didn't think those were proper goals for a kernel, even a UEFI Secure Boot kernel. He said, "the kernel should try to get away from the idea that UEFI Secure Boot should imply annoying restrictions. It's really annoying and it's never been clear to me that it has a benefit." He singled out the idea of preventing the root user from accessing kernel memory as one of these annoying restrictions.

Kees Cook replied with his overall justification for this patch. He said:

Go to Full Article