the latter Apple support article on Secure Boot has been updated recently:
YubiKey Full Disk Encryption
Tutorial to create full disk encryption with YubiKey, encrypted boot partition and secure boot with UEFI, using Arch Linux.
This repository contains a step-by-step tutorial to create a full disk encryption setup with two factor authentication (2FA) via YubiKey. It contains:
+ YubiKey encrypted root (/) and home (/home) folder on separated partitions
+ Encrypted /boot partition
+ UEFI Secure boot (self signed boot loader)
DRAFT: Take more than your usual care.
The SYSTEM_SECUREBOOT_POLICY_FULL_INFORMATION structure is what a successful call to ZwQuerySystemInformation or NtQuerySystemInformation produces in its output buffer when given the information class SystemSecureBootPolicyFullInformation (0xAB).
The SYSTEM_SECUREBOOT_POLICY_FULL_INFORMATION structure is not documented.
UEFI Secure Boot on Oracle Solaris x86 enables you to install and boot Oracle Solaris on platforms where UEFI Secure Boot is enabled. This feature provides more security by maintaining a chain of trust during boot: digital signatures of the firmware and software are verified before executing the next stage. No break occurs in the chain because of unsigned, corrupt, or rogue firmware or software during the boot process. This feature helps assure that the firmware and software used to boot Oracle Solaris on a hardware platform is correct, and has not been modified or corrupted.
This page was just updated:
Sorry, I didn’t do the detective work to see what has changed, I’ll leave that to you. 🙂
I wish there was some Microsoft Twitter/other feed that announced these changes…. ;-(
David Howells of Red Hat submitted a 16-part patch to the Linux-(Security,EFI,Kernel) mailing lists, with an interesting security patch for the Linux kenel. The patch includes contributions from: David Howells, Josh Boyer, Kyle McMartin, Matthew Garrett, and Dave Young. Quoting the patch announcement:
These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:
* No unsigned modules and no modules for which can’t validate the signature.
* No use of ioperm(), iopl() and no writing to /dev/port.
* No writing to /dev/mem or /dev/kmem.
* No hibernation.
* Restrict PCI BAR access.
* Restrict MSR access.
* No kexec_load().
* Certain ACPI restrictions.
* Restrict debugfs interface to ASUS WMI.
The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure. The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system. They are dependent for some EFI definitions on the keys-uefi branch.
Copy secure_boot flag in boot params across kexec reboot
Add the ability to lock down access to the running kernel image
efi: Get the secure boot status
efi: Lock down the kernel if booted in secure boot mode
efi: Disable secure boot if shim is in insecure mode
efi: Add EFI_SECURE_BOOT bit
hibernate: Disable when the kernel is locked down
acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
Add a sysrq option to exit secure boot mode
kexec: Disable at runtime if the kernel is locked down
PCI: Lock down BAR access when the kernel is locked down
x86: Lock down IO port access when the kernel is locked down
ACPI: Limit access to custom_method when the kernel is locked down
asus-wmi: Restrict debugfs interface when the kernel is locked down
Restrict /dev/mem and /dev/kmem when the kernel is locked down
x86: Restrict MSR access when the kernel is locked down
[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 RodsBooks.com — 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.
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:
Starting in late 2013, Microsoft Windows Defender, a background malware scanner that gets updates via Windows Update, started looking for UEFI boot managers/loaders/tools that are not signed by Microsoft, and started deleting them. This impacts booting non-Windows OSes, Linux, FreeBSD, Android, etc. Windows Defender gives users no control to override/configure anything. Microsoft can update the scanner to delete new files in the future, when Windows Update refreshes it. Presumably any UEFI image that isn’t signed by Microsoft is likely a candidate. I am unclear what “UEFI module” is they describe in the documentation (see below), I presume this means any UEFI Application/Service/Driver. The list of OEM contacts the Microsoft documentation points to for these “UEFI modules” is a very old list, doesn’t cover most UEFI Forum Members. Then again, some of the main targets of Defenders deletions are likely not OEMs nor UEFI Forum Members, but open source UEFI tools.
This feature is useful if you have a Windows system and you only run Windows, and never want to run anything other than Windows. This feature is not useful if you ever wish to dual-boot a non-Windows OS alongside Windows, since Windows Defender will destroy the other OS’s boot loader.
The workaround is to never dual-boot anything alongside Windows. OEMs who want to build non-Windows machines have to risk Windows Defender making their systems unbootable, if any customer tries to dual-boot Windows on it. I wonder, if an OEM is ever capable enough to ship a Linux system with UEFI Secure Boot setup to boot Linux, without Microsoft keys, would Windows Defender properly check the UEFI keys and delete the Windows boot manager, which is unsigned by that firmware? 🙂
Microsoft security advisory: Update to revoke noncompliant UEFI boot loader modules
“Microsoft is announcing the availability of an update for Windows 8 and Windows Server 2012 that revokes the digital signatures for nine private, third-party UEFI modules that could be loaded during UEFI Secure Boot. When the update is applied, the affected UEFI modules will no longer be trusted and will no longer load on systems where UEFI Secure Boot is enabled. The affected UEFI modules consist of specific Microsoft-signed modules that are either not in compliance with our certification program or their authors have requested that the packages be revoked. At the time of this release, these UEFI modules are not known to be available publicly. Microsoft is not aware of any misuse of the affected UEFI modules. Microsoft is proactively revoking these non-compliant modules as part of ongoing efforts to protect customers. This action only affects systems running Windows 8 and Windows Server 2012 that are capable of UEFI Secure Boot where the system is configured to boot via UEFI and Secure Boot is enabled. There is no action on systems that do not support UEFI Secure Boot or where it is disabled.”
“On affected releases of Microsoft Windows that are running on UEFI firmware with UEFI Secure Boot enabled, the update revokes the digital signatures for specific UEFI modules that could be loaded during UEFI Secure Boot. When the update is applied, the affected UEFI modules will no longer be trusted and will no longer load on systems where UEFI Secure Boot is enabled. The affected UEFI modules consist of specific Microsoft-signed modules that are either not in compliance with our certification program or their authors have requested that the packages be revoked.”
“For more information about your UEFI module, contact the UEFI module supplier. This might include the system vendor, the plug-in card vendor, or other UEFI software vendors such as UEFI backup and restore solutions, UEFI anti-malware, and so on.”
“Customers should update their UEFI modules to compliant versions prior to installation of this update. Customers who apply this update on a system with a non-compliant UEFI module risk putting the system into a non-bootable state. Microsoft recommends that all customers apply this update after ensuring they are running up-to-date UEFI modules.”
“Customers who want to continue using non-compliant UEFI modules for their own purposes, such as for testing, can do so by disabling Secure Boot in their system’s BIOS configuration menu.