Secure Boot: Difference between revisions
add information about sd-stub, key management and expand a bit the intro |
No edit summary |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
<languages/> | |||
<translate> | |||
<!--T:1--> | |||
Secure Boot usually refers to a platform firmware capability to verify the boot components and ensure that only your own operating system to boot. | Secure Boot usually refers to a platform firmware capability to verify the boot components and ensure that only your own operating system to boot. | ||
<!--T:2--> | |||
Secure Boot has multiple implementations, the most known one is UEFI Secure Boot, which relies on the UEFI platform firmware, but others implementations can exist on embedded systems. | Secure Boot has multiple implementations, the most known one is UEFI Secure Boot, which relies on the UEFI platform firmware, but others implementations can exist on embedded systems. | ||
<!--T:3--> | |||
On NixOS, Secure Boot can be enabled via the project [https://github.com/nix-community/lanzaboote Lanzaboote]. | On NixOS, Secure Boot can be enabled via the project [https://github.com/nix-community/lanzaboote Lanzaboote]. | ||
<!--T:4--> | |||
Lanzaboote has two components: <code>lzbt</code> and <code>stub</code>. | Lanzaboote has two components: <code>lzbt</code> and <code>stub</code>. | ||
<!--T:5--> | |||
<code>lzbt</code> is the command line that signs and installs the boot files on the ESP. | <code>lzbt</code> is the command line that signs and installs the boot files on the ESP. | ||
<!--T:6--> | |||
<code>stub</code> is a UEFI application that loads the kernel and initrd from the ESP, it's different from systemd-stub, see below to see precise differences. | <code>stub</code> is a UEFI application that loads the kernel and initrd from the ESP, it's different from systemd-stub, see below to see precise differences. | ||
<!--T:7--> | |||
{{warning|Lanzaboote is still in development and requires some prerequisites and precautions. Currently it's only available for nixos-unstable. For more information, please see the GitHub repository or the Quick Start guide.}} | {{warning|Lanzaboote is still in development and requires some prerequisites and precautions. Currently it's only available for nixos-unstable. For more information, please see the GitHub repository or the Quick Start guide.}} | ||
== Requirements == | == Requirements == <!--T:8--> | ||
<!--T:9--> | |||
The Secure Boot implementation of Lanzaboote requires a system installed in UEFI mode together with systemd-boot enabled. This can be checked by running <code>bootctl status</code>: | The Secure Boot implementation of Lanzaboote requires a system installed in UEFI mode together with systemd-boot enabled. This can be checked by running <code>bootctl status</code>: | ||
<!--T:10--> | |||
<syntaxHighlight lang=console> | <syntaxHighlight lang=console> | ||
$ bootctl status | $ bootctl status | ||
| Line 25: | Line 36: | ||
Boot into FW: supported | Boot into FW: supported | ||
<!--T:11--> | |||
Current Boot Loader: | Current Boot Loader: | ||
Product: systemd-boot 251.7 | Product: systemd-boot 251.7 | ||
| Line 30: | Line 42: | ||
</syntaxHighlight> | </syntaxHighlight> | ||
<!--T:12--> | |||
It is recommended to enable a BIOS password and full disc encryption to prevent attacks against UEFI and Secure Boot. | It is recommended to enable a BIOS password and full disc encryption to prevent attacks against UEFI and Secure Boot. | ||
== Setup == | == Setup == <!--T:13--> | ||
<!--T:14--> | |||
Follow the instructions in the [https://github.com/nix-community/lanzaboote/blob/master/docs/QUICK_START.md Quick Start guide]. | Follow the instructions in the [https://github.com/nix-community/lanzaboote/blob/master/docs/QUICK_START.md Quick Start guide]. | ||
<!--T:15--> | |||
== Key management == | == Key management == | ||
At the time of writing, Lanzaboote offers only local storage of the keyring, otherwise, it is not possible to rebuild the system and sign the new resulting files. | At the time of writing, Lanzaboote offers only local storage of the keyring, otherwise, it is not possible to rebuild the system and sign the new resulting files. | ||
<!--T:16--> | |||
In the future, Lanzaboote will offer two new signature backends: remote signing (an HTTP server which receives signature requests and answers with signatures) and PKCS#11-based signing (that is, bringing an HSM-like device, e.g. YubiKey, NitroKey, etc.). | In the future, Lanzaboote will offer two new signature backends: remote signing (an HTTP server which receives signature requests and answers with signatures) and PKCS#11-based signing (that is, bringing an HSM-like device, e.g. YubiKey, NitroKey, etc.). | ||
<!--T:17--> | |||
{{Warning|Key management is a hard problem which is out of scope for Lanzaboote project, many recipes exist and there is no single perfect solution. Taking the time to learn how to key manage and figure out the right level of threat protection is crucial to achieve an effective boot protection.}} | {{Warning|Key management is a hard problem which is out of scope for Lanzaboote project, many recipes exist and there is no single perfect solution. Taking the time to learn how to key manage and figure out the right level of threat protection is crucial to achieve an effective boot protection.}} | ||
<!--T:18--> | |||
== Differences with `systemd-stub` == | == Differences with `systemd-stub` == | ||
systemd and distribution upstream have an existing solution called `systemd-stub` but this is not a realistic solution for NixOS as there's too many generations on a system. | systemd and distribution upstream have an existing solution called `systemd-stub` but this is not a realistic solution for NixOS as there's too many generations on a system. | ||
<!--T:19--> | |||
Using `systemd-stub`, a kernel and an initrd has to be duplicated for '''each generation''', using Lanzaboote's stub, a kernel and initrd can be '''deduplicated''' without compromising on the security. | Using `systemd-stub`, a kernel and an initrd has to be duplicated for '''each generation''', using Lanzaboote's stub, a kernel and initrd can be '''deduplicated''' without compromising on the security. | ||
<!--T:20--> | |||
Tracking the feature parity with `systemd-stub` can be done in this issue: https://github.com/nix-community/lanzaboote/issues/94. | Tracking the feature parity with `systemd-stub` can be done in this issue: https://github.com/nix-community/lanzaboote/issues/94. | ||
[[Category:Security]] | [[Category:Security]] | ||
[[Category: | [[Category:Booting]] | ||
</translate> | |||
Latest revision as of 21:28, 12 July 2024
Secure Boot usually refers to a platform firmware capability to verify the boot components and ensure that only your own operating system to boot.
Secure Boot has multiple implementations, the most known one is UEFI Secure Boot, which relies on the UEFI platform firmware, but others implementations can exist on embedded systems.
On NixOS, Secure Boot can be enabled via the project Lanzaboote.
Lanzaboote has two components: lzbt and stub.
lzbt is the command line that signs and installs the boot files on the ESP.
stub is a UEFI application that loads the kernel and initrd from the ESP, it's different from systemd-stub, see below to see precise differences.
Requirements
The Secure Boot implementation of Lanzaboote requires a system installed in UEFI mode together with systemd-boot enabled. This can be checked by running bootctl status:
$ bootctl status
System:
Firmware: UEFI 2.70 (Lenovo 0.4720)
Secure Boot: disabled (disabled)
TPM2 Support: yes
Boot into FW: supported
Current Boot Loader:
Product: systemd-boot 251.7
...
It is recommended to enable a BIOS password and full disc encryption to prevent attacks against UEFI and Secure Boot.
Setup
Follow the instructions in the Quick Start guide.
Key management
At the time of writing, Lanzaboote offers only local storage of the keyring, otherwise, it is not possible to rebuild the system and sign the new resulting files.
In the future, Lanzaboote will offer two new signature backends: remote signing (an HTTP server which receives signature requests and answers with signatures) and PKCS#11-based signing (that is, bringing an HSM-like device, e.g. YubiKey, NitroKey, etc.).
Differences with `systemd-stub`
systemd and distribution upstream have an existing solution called `systemd-stub` but this is not a realistic solution for NixOS as there's too many generations on a system.
Using `systemd-stub`, a kernel and an initrd has to be duplicated for each generation, using Lanzaboote's stub, a kernel and initrd can be deduplicated without compromising on the security.
Tracking the feature parity with `systemd-stub` can be done in this issue: https://github.com/nix-community/lanzaboote/issues/94.