UK Gov security guidance for Ubuntu, including Secure Boot

The UK government has guidance on secure usage of Ubuntu. It appears to be newly-written.

Lots of useful information, and it mentions that Secure Boot is only active at some time: nice to see that level of detail.

Secure Boot section:

Secure boot validates the bootloader, kernel and kernel modules. However, some boot-related files are not protected by default and could be modified by an attacker to tamper with the boot process. Hardening of the boot process can help mitigate the risk.

Ubuntu does not use any dedicated hardware to protect its disk encryption keys. If an attacker can get physical access to the device, they can perform an offline brute-force attack to recover the encryption password.

Encryption keys protecting sensitive data remain available to an attacker when the device is locked. This means that if the device is attacked while powered on and locked, keys and data on the device may be compromised without the attacker knowing the password.

Ubuntu: DKMS modules need to be configured to work with UEFI Secure Boot

I just noticed this nice document on Ubuntu security features, maybe it is new, maybe I never noticed it before:

I also notice this page, which I believe has recently been updated:

DKMS modules need to be configured to work with UEFI Secure Boot

Ubuntu is now checking module signing by default, on kernels 4.4.0-18.34, 4.4.0-21.37, 4.2.0-42.49, 3.19.0-65.73 and 3.13.0-92.139 onwards. You can read more details in this bug in Launchpad. Because of those changes, DKMS modules will not work on systems with Secure Boot enabled unless correctly configured. In order to make DKMS work, Secure Boot signing keys for the system must be imported in the system firmware, otherwise Secure Boot needs to be disabled. There are several methods to configure your system to properly load DKMS modules with Secure Boot enabled.


ZFS-on-Root-Installer: Install ZFS on Root with Ubuntu

A Bare Metal Installer for ZFS on Root

This repository is intended to produce a bootable UEFI image that allows installing a full bare system with ZFS disks. Be aware that it is not intended for building dual-boot systems. While you are given the ability to choose which disks are used, the EFI boot system will wipe other OS entries. It uses an Ubuntu kernel and a minimal ramdisk builder to host the scripts used to perform the actual install.[…]


Ubuntu 17.10 corrupting BIOS – many Lenovo laptops models (and Acer and Toshiba)

“Canonical has pulled downloads for its Ubuntu 17.10 Linux distribution following reports that it can trigger a bug in the UEFI firmware of selected Lenovo, Acer, and Toshiba laptops, corrupting the BIOS and disabling the ability to boot from USB Drives.”

Thunderbolt-software-user-space in Ubuntu

Colin Ian King of Canonical has been packaging up the Intel Thunderbolt user-space software for Ubuntu. His Tweets are private, but he just tweeted that the tool is now in Ubuntu!

Thunderbolt user-space components:

[…]The user-space components implement device approval support:
* Easier interaction with the kernel module for approving connected devices.
* ACL for auto-approving devices white-listed by the user.

So far, I’ve not found a public security page for Thunderbolt. Only a “Fun Facts” page… 😦 I was hoping to find a page listing Thunderstrike, Thunderstrike2, the Legbacore t2e tool, CIA Sonic Screwdriver, PCILeech, etc.

Hyper-V UEFI bootloader complexities

[…]Forcing GRUB installation to EFI removable media path does basically the same thing as when Ubuntu installer asks you if you want to force UEFI installation: it installs to the removable media path in the ESP (EFI System Partition). This is fine for environment where no other operating system is present. However if there is another operating system present on the device which depends on this fallback location “removable media path” it will make this system temporary unbootable (you can manually configure GRUB later to boot it if necessary though). Windows installer for example *also* installs to the removable media path in the ESP. All OS installers installing things to this removable media path will conflict with any other such installers and that’s why in Debian (and Ubuntu) installers don’t do this by default. You explicitly have to select UEFI mode during the normal installation (what I did).[…]

OpenCIT 2.2 released

Adolfo V Aguayo of Intel announced the version 2.2 release of OpenCIT.

New Features in 2.2:
– TPM 2.0 support.
   + Added support for platform and asset tag attestation of Linux and Windows hosts with TPM 2.0.
   + Support attestation of either SHA1 or SHA256 PCR banks on TPM 2.0.
   + Ubuntu 16.04 and RHEL 7.2, 7.3 (SHA1 and SHA256), Windows Server 2012 and Hyper-V Server 2012 (SHA1) are supported with TPM 2.0
– All the certificates and hashing algorithms used in CIT are upgraded to use SHA256.  SHA1 has been deprecated and will no longer be used.
– CIT Attestation Service UI has been updated to allow the user to select either the SHA1 or SHA256 PCR bank for Attestation of TPM 2.0 hosts.
    + The CIT  Attestation Service will automatically choose the strongest available algorithm for attestation (SHA1 for TPM 1.2, and SHA256 for TPM 2.0)
– CIT Attestation Service UI Whitelist tab no longer requires the user to select PCRs when whitelisting, and will automatically choose the PCRs to use based on the host OS and TPM version.  This is done to reduce confusion due to differing behaviors between TPM 1.2 and TPM 2.0 PCR usages.
– Additional changes made to support TPM 2.0:
    + Linux hosts with TPM 2.0 will now utilize TPM2.0-TSS (TPM 2.0 Software Stack) and TPM2.0-tools instead of the legacy trousers and tpm-tools packages. The new TSS2 and TPM2.0-tools are packaged with the CIT Trust Agent installer.
    + TPM 2.0 Windows hosts use TSS.MSR (The TPM Software Stack from Microsoft Research) PCPTool.
    + TPM 1.2 hosts will continue to use the legacy TSS stack (trousers) and tpm-tools components.

For more information, see the full announcement on the mailing list.

SeaBIOS ACPI patch fixing Ubuntu/Windows installs

Bin Meng posted an 18-part patch to the SeaBIOS list, fixing multiple issues that may impact the installation of Ubuntu (only Ubuntu and no other Linux distros??) and Windows:

[PATCH v2 00/18] x86: acpi: Support installation of Ubuntu/Windows and boot Windows

SeaBIOS can be loaded by U-Boot to aid the installation of Ubuntu and Windows to a SATA drive and boot from there. But till now this is broken. The installation either hangs forever or just crashes. This series fixed a bunch of issues that affect the installation of Ubuntu and Windows, and booting Windows.

Testing was performed on MinnowMax by:
– Install Ubuntu 14.04 and boot
– Install Windows 8.1 and boot
– Install Windows 10 and boot

This series is available at u-boot-x86/acpi2-working.

Changes in v2:
– New patch to remove the unnecessary checksum calculation of DSDT
– New patch to remove header length check when writing tables
– New patch to enable SeaBIOS on all boards
– New patch to add GPIO ASL description

Bin Meng (18):
  x86: minnowmax: Adjust U-Boot environment address in SPI flash
  x86: Call board_final_cleanup() in last_stage_init()
  x86: Fix up PIRQ routing table checksum earlier
  x86: Compile coreboot_table.c only for SeaBIOS
  x86: Prepare configuration tables in dedicated high memory region
  x86: Unify reserve_arch() for all x86 boards
  x86: Reserve configuration tables in high memory
  x86: Use high_table_malloc() for tables passing to SeaBIOS
  x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM
  x86: acpi: Remove the unnecessary checksum calculation of DSDT
  x86: acpi: Remove header length check when writing tables
  x86: doc: Update information about IGD with SeaBIOS
  x86: baytrail: Enable SeaBIOS on all boards
  x86: doc: Mention Ubuntu/Windows installation and boot support
  acpi: Quieten IASL output when ‘make -s’ is used
  x86: baytrail: Add internal UART ASL description
  x86: baytrail: Add GPIO ASL description
  x86: doc: Add porting hints for ACPI with Windows

For more information, see the U-Boot list:

ubuntu-secure-boot package

James Johnson has a project to help make Secure Boot on Ubuntu. Excerpt of readme:

ubuntu-secure-boot package

The stock Ubuntu 15.10 installation only implements secure boot just enough to get a Microsoft-signed shim in place.  It does nothing to actually secure the boot process.  This package can help users do so.

Features of ubuntu-secure-boot:
* Self-signed bootloader files: take control over your boot process by stripping Canonical / Microsoft signatures from your boot files and signing everything yourself.
* Summary of files that are digitally signed and verified during the boot process are:
    * GRUB itself (self-signed)
    * GRUB configuration (self-signed)
    * GRUB modules and other external files (self-signed)
    * Linux kernel (self-signed)
    * Linux initramfs / initrd (self-signed)
    * Linux kernel modules (using existing Canonical signatures)
* Self-signed private keys are stored in /etc/ubuntu-secure-boot/keys and protected by a passphrase.
* UEFI Secure Boot self-signed key pairs are generated and used to sign the self-contained GRUB .efi image.  They can be imported into a UEFI firmware  to take full control over the secure boot process.
* The secure GRUB image is added as a boot option in EFI firmware.
* Digital signature support in GRUB is enabled to check signatures on any boot file that is loaded from disk.  The risk of loading an unsigned file from GRUB is eliminated (e.g. an unsigned kernel).
* GRUB is now deployed as a stand-alone .efi image that contains a memdisk with the full configuration and all loadable modules.  This eliminates the risk of tampering with the GRUB configuration.
* GRUB is automatically locked down with a password so that users cannot tamper with boot settings or use advanced boot options.
* Unsigned GRUB files in /boot remaining from the original GRUB packages are completely wiped (but restored upon uninstall of this package).
* Newly-installed kernels are automatically signed whenever they are installed. Existing Canonical .efi signatures in the linux-signed-image-* packages are stripped and replaced with your signature.
* The initramfs is automatically re-signed whenever update-initramfs is run.
* Linux kernel module signing enforcement is automatically enabled by default. This can be controlled from /etc/default/grub.d/ubuntu-secure-boot.cfg.

Ubuntu to opt-out of fwupd?

Not only do you have to study your Linux distribution to see if/how it uses Secure Boot, you also need to research if/how it gets firmware updates.

“Ubuntu should support updating firmware for systems and components (but not peripherals) via EFI UpdateCapsule (see EFI Capsule specification, in Related Links), so that users do not require Windows or DOS to apply BIOS/component firmware updates, and as such updates are easily available to all Ubuntu users. Peripheral firmware updates are not technically supported by the UEFI Capsule specification, and so are out of the scope of this blueprint.”

I also wonder about non-GNOME systems, how do KDE systems get firmware updates?

Ubuntu’s UEFI Secure Boot: not a security measure

[[UPDATE: As Teddy Reed points out, this information is in the Ubuntu wiki, not just in a Ubuntu bug report:

IMPORTANT: Canonical’s Secure Boot implementation in Ubuntu 15.10 and early is primarily about hardware-enablement and this page focuses on how to test Secure Boot for common hardware-enablement configurations, not for enabling Secure Boot to harden your system. If you want to use Secure Boot as a security mechanism, an appropriate solution would be to use your own keys (optionally enrolling additional keys, see above) and update the bootloader to prohibit booting an unsigned kernel. Ubuntu 16.04 LTS is planned to enable enforcing secure boot (see LP: #1401532 for details). “]]

Research the implementation of UEFI Secure Boot by a Linux/FreeBSD distro before presuming to rely on it to provide any security. 😦

“Ubuntu’s support for secure boot is solely intended as a compatibility measure so that media can boot on secure boot enabled computers. There are no current plans to enable secure boot as a security measure.”


Intel Platform QoS tool for Linux

Colin King of Canonical has a new blog post on Intel’s Cache Monitoring Tool, and Intel’s Ubuntu implementation:

The Intel Platform Shared Resource Monitoring features were introduced in the Intel Xeon E5v3 processor family. These new features provide a mechanism to measure platform shared resources, such as L3 cache occupancy via Cache Monitoring Technology (CMT) and memory bandwidth utilisation via Memory Bandwidth Monitoring (MBM). Intel have written a Platform Quality of Service Tool (pqos) to use these monitoring features and I’ve packaged this up for Ubuntu 16.04 Xenial Xerus.” […]

FWTS updated

Ivan Hu of Canonical has announced the release of FWTS (FirmWare TestSuite), to 5.09.00. FWTS is a set of command line tools for Ubuntu-based and related Linux systems. It also includes a curses-based interface frontend, which is also the default UI to FWTS-live. FWTS is also included in LUV, the Linux UEFI Validation distribution, but it may be a few days until this latest release has been updated in LUV-live. The release features many bugfixes, as well as some new updates/features, including:

* Update ACPICA to version 20150717
* SMBios 3.0.0 tests supported
* acpi: add _CR3 test
* acpi: add _MTL test
* acpi: add _RST test
* acpi: add _PRR test
* dmicheck: SMBIOS 3.0.0 test

For more information, see the full announcement on the fwts-announce mailling list, and see the full changelog, /usr/share/doc/fwts/changelog.Debian.gz in the source tarball.

FWTS 15.08.00 released

Today Canonical has released version 15.08.00 of FWTS (FirmWare Test Suite), a set of firmware-related tests for Linux-based systems. The tests can be run via command line, or via a curses front-end, the latter of which is used by the FWS-live distribution. FWTS is also included in Intel’s LUV-live (Linux UEFI Validation) distribution, but it’ll take LUV a bit of time to update to new FWTS release. FWTS is also available as packages on Ubuntu-based distributions.

It appears that most new features are ACPI-related. New ACPI TPM2 and IORT tests, new tables for: FPDT, MCHI, STAO, ASF!, WDAT, and a few other things. There were a lot of bugfixes as well. For more information, see the full announcement, the changelog, and sources:

I wish ALL Linux/FreeBSD distributions would ship FWTS, not just Ubuntu-based ones: FTWS is very useful to detect if system has anomalies which’ll make it difficult to install/use the OS. Granted, those distro uses can just use FWTS-live, but they have to reboot into FWTS-live to use FWTS, with no native packaging.

Tutorial on using EDK-II’s Linux emulator

Today Jey Jay (LinuxKernelSeeker) has a blog post on how to use TianoCore with Linux, using the EDK2 emulator.

“This post will explains the steps involved in compiling EmulatorPkg of Tianocore EDK2. Who wish to learn UEFI can use this emulator for writing UEFI samples.” …

It is a good article, some of the Tianocore readmes for Linux are fairly vague (and/or referencing outdated distro releases that’re no longer available), so it is nice to have a tutorial talking about a fresh release, including some screenshots to be even more user-friendly.

More Information:

Secure Boot strength varies by Linux implementation

[UPDATE, with input from readers, see EOM. Thanks!]

UEFI Secure Boot is a build-time feature of UEFI that helps secure the boot process from some boot-time attacks, optionally using TPM hardware if available. Secure Boot became widespread on Windows hardware during Windows 8 timeframe. Windows aside, other operating systems have to support UEFI Secure Boot. Linux supports UEFI and UEFI Secure Boot (as does FreeBSD). Different Linux distributions have different Linux kernels, with different versions, different patchsets, and different build-time directives enabled. So, Fedora’s Linux kernel is different than SuSE’s Linux kernel, etc.

I saw a recent comment from a UEFI security researcher who had been building a Linux liveboot CD and running CHIPSEC — which includes a native Linux kernel driver, and running it on UEFI systems with Secure Boot enabled.

“Ubuntu appears to have shim and do secure boot but not enforce kernel module signing.”

This Ubuntu behaviour was a change in behaviour from the Fedora-based systems the researcher was used to using. I was curious about the difference in distros w/r/t enforcing kernel module signing. So I asked on the FirmWare TestSuite (FWTS) list if there was a test for this. Roderick W. Smith of Canonical — and author of rEFInd boot manager and the definitive Linux boot loader/manager reference on — replied clarifying the situation:

“Yes, that’s correct. Ubuntu’s kernel doesn’t attempt to enforce Secure Boot policy beyond the main kernel file; once the kernel’s loaded, it’s possible to load an unsigned kernel module. Fedora, as you inferred, does require signing of kernel modules. Fedora’s approach is arguably more secure, since an attacker can’t load a malicious kernel module once the system has booted, but leads to problems with third-party kernel modules, like the in-kernel portions of nVidia and ATI/AMD video drivers. FWIW, the decision to do it this way was made before I joined Canonical, so I’m not sure who made the decision.”

Ivan of Canonical replied with more information:

“On Linux, two stage booting has implemented for secureboot. First stage is firmware boot to shim and then shim will take care to check signature and boot with grub and kernel. Booting with/without kernel signed is under shim and grub implementation, Ubuntu provides the singed kernel in official releases, and would like to keep the flexibility for user to build their kernel, so Ubuntu doesn’t block booting when user uses unsigned kernel.”

The security researcher who reported this speculated that Canonical’s policy may be due to them not wanting to put their distro signature (or perhaps worry about license issues in doing so) on some 3rd party (non open) binary.

As I understand things, this is beyond the strict “UEFI Secure Boot” definition, and on to what OS-centric post-UEFI Secure Boot security techniques it will implement. I guess some call it “OS Secure Boot” to differentiate it from “UEFI Secure Boot”, but I don’t see any formal definition for that term.

I wish there was more precise information about Secure Boot implementation from each Linux distro. System administrators and technical support engineers will need to know these nuances, as will security researchers. Pehaps Linux Foundation or UEFI Forum — or some Wikipedian(s) — could help with a comparison of Secure Boot on different OSes? Perhaps FWTS or CHIPSEC could have a test to check? Perhaps the UEFI Forum could note these nuances at their next plugfest, and setup test cases combinining Linux OSVs with a test case that loads dynamically load native OS drivers: perhaps using CHIPSEC as the test case may suffice, it loads a native helper driver.

So, don’t just look at if Secure Boot is enabled or not, look at what Linux OS you’re using, and how it implements Secure Boot. And remember attackers are also making this choice, and looking for your softer Linux targets, so be more careful when using those systems.


Updated information:

The reason this issue came up is that the researcher was using Intel CHIPSEC, which when run on Linux it uses a Linux kernel module. Unlike most drivers, which get loaded when OS initializes, then stay loaded, the CHIPSEC driver behaves differently. The CHIPSEC userland Python app compiles the kernel module, and loads the module when it starts, then unloads the driver when it finishes (because the driver enables risky things, see it’s warning.txt). On Fedora, this kind of CHIPSEC driver loading behavior will not work, with Secure Boot enabled, until you setup moklist and sign the module. By contrast with Fedora, on Ubuntu, CHIPSEC is able to load the unsigned driver without the user having to change anything (convenience). Here’s more information on how Fedora does it’s module signing process: