Ensuring the security of our systems and data is among Two Sigma’s highest priorities. We also believe it’s important to contribute actively to the open source security community, to help improve the usable security of everyone’s systems.
Over the years, we’ve invested both in supporting open source tools that provide a secure foundation, as well as in fundamental security research. Two Sigma employees lead or contribute to many projects that help secure the systems of the Internet, like OpenSSL, Kerberos, and BSD, and they have also helped to start projects like Heads and LinuxBoot, which are exploring how to build slightly more secure systems with open firmware.
Introducing safeboot
In the same spirit, Two Sigma is supporting the development of safeboot.dev, a package that helps improve the usable security of the boot process for modern Debian-based x86 computers.
safeboot makes it easy to take advantage of many of the security features that are already built into recent UEFI firmware. These include enrolling your own key as the Platform Key to ensure that the system will only boot the kernel and initrd that you have signed, while also streamlining the boot process by protecting the disk encryption keys in the Trusted Platform Module (TPM) hardware, so that no passphrase is required to unlock the disk. safeboot also makes it easier to make use of Linux-specific features like cryptographic signatures on read-only filesystems and deprivileging the root user.
Using a TPM2 sealed disk encryption key, protected by a user PIN, the TPM PCRs and a monotonic TPM counter, makes it significantly more difficult for a physical attacker to be able to use the encrypted disks outside of the system, as well as making it less likely that rogue hardware, firmware, or software will be able to tamper with the boot process or even roll back to insecure versions of the firmware. These sorts of protections are also used by Microsoft for Secure Boot and Bitlocker to help secure enterprise systems, and are easier to deploy on Linux systems with safeboot.
safeboot also improves the system’s resiliency by detecting attempts by an attacker to gain persistence in the operating system, and providing attestation to a remote system that the firmware, kernel, initrd, and root filesystem have not been modified by an attacker.
Why safeboot isn’t the Linux default
Most stock Linux distributions are for general users who don’t have the exact threat model of a firm like Two Sigma. There are also usability issues with configuring UEFI firmware on different machines, as well as the risk of losing your data if you lose access to the keys. For corporate-managed machines, however, or for computer owners who need this sort of protection, the features are there and just need to be enabled.
Other features like pre- and post-boot IOMMU DMA protection, or configurations like the Linux kernel’s confidentiality lockdown mode are not suitable for every user and hardware, so enabling them by default might break on some people’s systems. Since Linux distributions typically want to “just work” on the largest number of computers for the largest number of users, these features are not turned on. However, for users or organizations that are concerned about these sorts of threats, safeboot’s threat model and open source implementation makes it easier to reason about what protections are necessary to protect against different threats, as well as the potential usability trade-offs of enabling those protections.
In many ways corporate laptops are similar to Edge Computing systems, in that potential adversaries have physical access for extended periods of time, including access to internal buses. They might be able to coerce insiders with user level privileges to reveal passwords, rollback firmware or software to vulnerable versions, write unauthorized data to unencrypted filesystems, install hardware implants, and so on. While not all attacks can be defended against, safeboot’s goal is that physical access is not “game over” for security. It is possible to detect many attacks through techniques like sealed secrets and remote attestation, and to provide enough system resiliency to potentially recover from the attacks.
How safeboot can help organizations running Linux laptops
One of the advantages of open source security software like safeboot is that it is easy to customize the configuration to the specific concerns of the computer owner. “Your threat model is not my threat model”, although most threat models have enough similar pieces that tools like safeboot can be easily configured to match. The goal is to be able to develop and deploy usable security that protects against the likely risks and allows remote detection of attacks or failures.
Like many organizations, Two Sigma’s threat model includes locking down the systems that we’re deploying. Additionally, with many employees working from home amid the Covid-19 pandemic, it is even more important that organizations be able to secure and remotely verify the laptops that they are using.
In Two Sigma’s case, with safeboot on our Linux laptops, we can have more trust that they are running only our signed code and locked-down configuration. These protections are active when the computers are used offline – the TPM will not unseal the disk encryption key if any of the software is modified. Additionally, when the computer connect to our remote access systems, our servers can validate the TPM’s attestation that the firmware, kernel, and runtime are unaltered. In the event of an attestation failure or tamper event detection, the systems can be secured against unsealing secrets until a forensic examination can be performed.
What’s next for safeboot?
While safeboot is usable today, there are always improvements that will help improve the usable security of the system. Currently Ubuntu 20.04 is the supported distribution, although supporting more Linux distributions is on the roadmap. Also under development is adding UEFI SecureBoot and safeboot integration to Xen hypervisor, which will help improve the boot-time security of Qubes “reasonably secure operating system”.
There are also improvements needed for managing a fleet of safeboot laptops. The TPM PCRs are never the same across different models of machines, so having a better way to manage the signatures on the TPM sealed data is important. Another fleet management issue is better upgrades for the read-only root filesystem; the LVM snapshots can be used to perform atomic updates, although there is more tooling required for this to be usable.
And there is also work on integration with cosign and hardware tokens to require multiple trusted administrators to sign off on a new release, which will help reduce the threat of a single rogue insider from being able to build a backdoored system.
If you want to try out safeboot on your own system you can download the source from github.com/osresearch/safeboot and follow the instructions on safeboot.dev/install to configure it and lockdown your laptop. If you want to contribute to the project, there are open issues on the github page for new features and enhancements, several of which are tagged with “good first issue.”
