adaedra/blog
1
0
Fork 0
Code Issues Activity

Note and warning styles

Browse Source
This commit is contained in:
Thibault “Adædra” Hamel 2024-06-16 00:33:03 +02:00
parent 5f8b9b4228
commit b7569e01e9
2 changed files with 48 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
articles/arch-uki-secure-boot/arch-uki-secure-boot.asciidoc
View File

@ -15,7 +15,8 @@ We are going to make an Arch Linux installation boot from UEFI. This can be done
This guide will also show how to make it compatible with https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot[Secure Boot]. Secure Boot is a bit of a problematic feature in the Linux community, and some people prefer to leave it out. I am not going to argue for or against it, I am just presenting how to make it compatible, but this part is completely optional. However, if you want to go with Secure Boot, you need to boot your machine with Secure Boot enabled and in Setup mode. This guide will also show how to make it compatible with https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot[Secure Boot]. Secure Boot is a bit of a problematic feature in the Linux community, and some people prefer to leave it out. I am not going to argue for or against it, I am just presenting how to make it compatible, but this part is completely optional. However, if you want to go with Secure Boot, you need to boot your machine with Secure Boot enabled and in Setup mode.
Note: Arch Linux now provides multiple choices for the https://wiki.archlinux.org/title/Arch_boot_process#initramfs[initramfs]. https://wiki.archlinux.org/title/Mkinitcpio[mkinitcpio] has been the historical and still default choice today, but it is also possible to use https://wiki.archlinux.org/title/Dracut[dracut] or https://wiki.archlinux.org/title/Booster[booster]. dracut supports making an UKI image directly, and there is `+systemd-ukify+` that can make an UKI image from separate kernel and initramfs. However, this article will focus on mkinitcpio. [.note]
Arch Linux now provides multiple choices for the https://wiki.archlinux.org/title/Arch_boot_process#initramfs[initramfs]. https://wiki.archlinux.org/title/Mkinitcpio[mkinitcpio] has been the historical and still default choice today, but it is also possible to use https://wiki.archlinux.org/title/Dracut[dracut] or https://wiki.archlinux.org/title/Booster[booster]. dracut supports making an UKI image directly, and there is `+systemd-ukify+` that can make an UKI image from separate kernel and initramfs. However, this article will focus on mkinitcpio.
== Making the install == Making the install
@ -72,7 +73,8 @@ Congratulations! You now boot entirely through your UKI image.
== Secure Boot == Secure Boot
Note: As said above, this step is optional, if you do not want to use Secure Boot. [.note]
As said above, this step is optional, if you do not want to use Secure Boot.
Secure Boot is an addition to UEFI that ensures that your boot sequence has not been tampered with, by requiring all boot images to be signed with a valid certificate. By default, machines have two Microsoft-provided certificates, one for Windows, one for third party systems, the latter being used by some distributions to provide some level of support to Secure Boot. You can also register your own certificate into the machine to sign your own binaries, which is what we are going to set up here. Once setup correctly, the signing process is automatic. Secure Boot is an addition to UEFI that ensures that your boot sequence has not been tampered with, by requiring all boot images to be signed with a valid certificate. By default, machines have two Microsoft-provided certificates, one for Windows, one for third party systems, the latter being used by some distributions to provide some level of support to Secure Boot. You can also register your own certificate into the machine to sign your own binaries, which is what we are going to set up here. Once setup correctly, the signing process is automatic.
@ -86,7 +88,8 @@ Secure Boot: ✗ Disabled
Vendor Keys: none Vendor Keys: none
.... ....
Note: `+sbctl+` might also indicate that it is _not_ installed, but this will correct itself in the next steps. [.note]
`+sbctl+` might also indicate that it is _not_ installed, but this will correct itself in the next steps.
If it is not, you will have to reboot your machine into the firmware interface to enable it. Some firmware will go into Setup mode by choosing to erase all certificates. If it is not, you will have to reboot your machine into the firmware interface to enable it. Some firmware will go into Setup mode by choosing to erase all certificates.
@ -97,7 +100,8 @@ sbctl create-keys
sbctl enroll-keys -m sbctl enroll-keys -m
.... ....
Warning: `+-m+` tells `+sbctl+` to also insert the standard Microsoft certificates, which allows to boot Windows. Even if you plan on never booting Windows, some systems might have UEFI-drivers to load on boot that use one of these certificates. Not including them could break your boot sequence. You can technically do without, but be sure of what you are doing there. [.warning]
`+-m+` tells `+sbctl+` to also insert the standard Microsoft certificates, which allows to boot Windows. Even if you plan on never booting Windows, some systems might have UEFI-drivers to load on boot that use one of these certificates. Not including them could break your boot sequence. You can technically do without, but be sure of what you are doing there.
Now that we have our certificates, we need to sign our UKI images. Fortunately, `+sbctl+` also includes a hook for `+mkinitcpio+` to do it for you. You should just have to regenerate images with `+mkinitcpio -P+`. Once this done, ensure it is all good with `+sbctl verify+`: Now that we have our certificates, we need to sign our UKI images. Fortunately, `+sbctl+` also includes a hook for `+mkinitcpio+` to do it for you. You should just have to regenerate images with `+mkinitcpio -P+`. Once this done, ensure it is all good with `+sbctl verify+`:
@ -115,7 +119,8 @@ sbctl sign -s /boot/efi/EFI/…
The `+-s+` flag tells `+sbctl+` to remember this path. In the future, if you modify any of those files, you can just issue `+sbctl sign-all+` to check and resign every known file. The `+-s+` flag tells `+sbctl+` to remember this path. In the future, if you modify any of those files, you can just issue `+sbctl sign-all+` to check and resign every known file.
Warning: Ensure that `+sbctl verify+` validates your boot files before rebooting! If you reboot without signing your files, your system will refuse to boot, now that the certificates are registered. [.warning]
Ensure that `+sbctl verify+` validates your boot files before rebooting! If you reboot without signing your files, your system will refuse to boot, now that the certificates are registered.
You can now reboot your machine to check that it still boots. Once you reboot, `+sbctl status+` should tell you that all is well: You can now reboot your machine to check that it still boots. Once you reboot, `+sbctl status+` should tell you that all is well:
@ -133,13 +138,15 @@ While this is enough for a functional setup, I have some personal tweaks to this
=== Automatic root decryption === Automatic root decryption
Note: Requires Secure Boot, a https://wiki.archlinux.org/title/Trusted_Platform_Module[TPM], and a LUKS 2 encrypted root. [.note]
Requires Secure Boot, a https://wiki.archlinux.org/title/Trusted_Platform_Module[TPM], and a LUKS 2 encrypted root.
If your root partition is encrypted, you have to enter the passphrase at every boot. If you have a TPM, you can use it to automatically provide this passphrase to the system. While this seem like a downgrade in security, your system is normally still password protected at the login prompt, so your data should be safe, but it is your choice between more security and ease of use. However, it becomes dangerous if coupled with auto-login! If your root partition is encrypted, you have to enter the passphrase at every boot. If you have a TPM, you can use it to automatically provide this passphrase to the system. While this seem like a downgrade in security, your system is normally still password protected at the login prompt, so your data should be safe, but it is your choice between more security and ease of use. However, it becomes dangerous if coupled with auto-login!
The boot process and the TPM will ensure that your system has not been tempered with. It means that it will compare Secure Boot certificates at boot and will refuse to use the saved credentials if they are modified, which is even stronger than the base Secure Boot check. The boot process and the TPM will ensure that your system has not been tempered with. It means that it will compare Secure Boot certificates at boot and will refuse to use the saved credentials if they are modified, which is even stronger than the base Secure Boot check.
Note: This does not save your passphrase in the firmware. It uses a different LUKS slot with its own data saved into the TPM. The safety of the passphrase itself is not affected. [.note]
This does not save your passphrase in the firmware. It uses a different LUKS slot with its own data saved into the TPM. The safety of the passphrase itself is not affected.
systemd provides the `+systemd-cryptenroll+` command to make the process easy. First, check that your TPM device is detected: systemd provides the `+systemd-cryptenroll+` command to make the process easy. First, check that your TPM device is detected:
@ -157,7 +164,8 @@ Replace `+/dev/vda2+` by your root partition physical device (the encrypted laye
Reboot, and you should not have to input your passphrase anymore. Reboot, and you should not have to input your passphrase anymore.
Note: Security of this depends on what is allowed to boot on your machine. I would advise to lock down your UEFI settings with a password, including the boot menu if possible, making changing the default boot device impossible for an external person. Of course, they can reset the firmware with a physical access, but that would also reset the boot certificates and make the TPM decryption impossible. If you still keep a bootloader, be careful of what it allows to load. [.note]
Security of this depends on what is allowed to boot on your machine. I would advise to lock down your UEFI settings with a password, including the boot menu if possible, making changing the default boot device impossible for an external person. Of course, they can reset the firmware with a physical access, but that would also reset the boot certificates and make the TPM decryption impossible. If you still keep a bootloader, be careful of what it allows to load.
=== rEFInd === rEFInd
@ -186,4 +194,5 @@ PRESETS=('fallback' 'default')
You can now close the preset file. Recreate the parent folder with `+mkdir+`, then run `+mkinitcpio -P+` to re-create the images in the right order. You can now close the preset file. Recreate the parent folder with `+mkdir+`, then run `+mkinitcpio -P+` to re-create the images in the right order.
Note: If you have Secure Boot set up, do not forget to sign its image with `+sbctl+`. [.note]
If you have Secure Boot set up, do not forget to sign its image with `+sbctl+`.

30
src/index.css
View File

@ -188,3 +188,33 @@ a {
max-width: 100%; max-width: 100%;
margin: 0 auto; margin: 0 auto;
} }
.warning, .note {
border-inline-start-width: 0.2em;
border-inline-start-style: solid;
padding-inline-start: 0.8em;
margin-inline-start: -1em;
&::before {
display: block;
margin-bottom: 0.5em;
}
}
.warning {
border-inline-start-color: var(--gruvbox-light-orange);
&::before {
content: "Warning";
color: var(--gruvbox-light-orange);
}
}
.note {
border-inline-start-color: var(--gruvbox-light-aqua);
&::before {
content: "Note";
color: var(--gruvbox-light-aqua);
}
}