Update after Morten Linderud comments
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
Some sentenses were badly worded and did not convey the meaning I intended. There also was a blatent error regarding the number of UEFI executables signed with the Microsoft Third Party CA.
This commit is contained in:
parent
33dfef3746
commit
e2a372f00a
1 changed files with 30 additions and 25 deletions
|
@ -30,12 +30,13 @@ software.
|
||||||
|
|
||||||
## Secure Boot, the technology
|
## Secure Boot, the technology
|
||||||
|
|
||||||
Secure Boot[^spec] is an attempt at ensuring that only authorized software is run on a
|
Secure Boot[^spec] helps running only authorized software on a machine. It
|
||||||
machine. It does so by bootstrapping the security of the system at boot time,
|
does so by bootstrapping the security of the system at boot time, by verifying
|
||||||
giving way to other technologies to keep the system secure, later on. Secure
|
signatures on various software components, before giving way to other
|
||||||
boot works by authorizing only select executables to be run. Authorized
|
technologies to keep the system secure, later on. Secure boot works by
|
||||||
executables are signed using public cryptography, and the keys used to verify
|
authorizing only select executables to be run. Authorized executables are
|
||||||
those signatures are stored securely in UEFI "databases".
|
signed using public cryptography, and the keys used to verify those signatures
|
||||||
|
are stored securely in UEFI "databases".
|
||||||
|
|
||||||
[^spec]: [UEFI Specifications](https://uefi.org/specs/access)
|
[^spec]: [UEFI Specifications](https://uefi.org/specs/access)
|
||||||
|
|
||||||
|
@ -48,17 +49,19 @@ the case of GNU/Systemd/Linux, the bootloader runs the Linux kernel, which
|
||||||
shuts down all UEFI Boot Services, before dropping its privileges and then
|
shuts down all UEFI Boot Services, before dropping its privileges and then
|
||||||
doing "Linux stuff" (like starting the userland part of the operating system).
|
doing "Linux stuff" (like starting the userland part of the operating system).
|
||||||
This privilege drop is very important because this is what ensures that no code
|
This privilege drop is very important because this is what ensures that no code
|
||||||
past that point is able to tamper with the UEFI environment, including UEFI
|
past that point is able to tamper with the UEFI sensitive information,
|
||||||
variables, which contains sensitive data.
|
including UEFI variables, which contains sensitive data.
|
||||||
|
|
||||||
Secure Boot aims at securing "everything" that is executed prior to that
|
Secure Boot aims at securing "everything" that is executed prior to that
|
||||||
privilege drop. Once the privileges are drop, it is up to the operating system
|
privilege drop. Once the privileges are drop, Secure Boot is done and it is up
|
||||||
to ensure that only authorized software is run. Most Linux distros do not even
|
to the operating system to extend that integrity/authenticity protection and
|
||||||
try to do it, although there are notable exceptions (Chrome OS, Android, just
|
ensure that only authorized software is run. Most Linux distros do not even try
|
||||||
to name a few). If we run one of the distros that do not leverage technologies
|
to do it, although there are notable exceptions (Chrome OS, Android, just to
|
||||||
|
name a few). If we run one of the distros that do not leverage technologies
|
||||||
such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity
|
such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity
|
||||||
Management Architecture), then Secure Boot is strictly insufficient to protect
|
Management Architecture), then Secure Boot protected the boot integrity for
|
||||||
user data integrity or even system integrity in general.
|
basically nothing, because the security chain is broken by the operating
|
||||||
|
system, and user data is at risk from possibly any tainted userland executable.
|
||||||
|
|
||||||
Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux
|
Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux
|
||||||
security guide[^linuxguide] to enable Secure Boot (R3) for all systems
|
security guide[^linuxguide] to enable Secure Boot (R3) for all systems
|
||||||
|
@ -88,11 +91,12 @@ attempts to prove that it is not only useless but incoherent and misleading.
|
||||||
Secure boot relies on a set of public keys to verify authorized software
|
Secure boot relies on a set of public keys to verify authorized software
|
||||||
authenticity. By default, most vendors ship Microsoft public keys. These keys
|
authenticity. By default, most vendors ship Microsoft public keys. These keys
|
||||||
sign all Microsoft Windows version, of course, but to avoid a monopoly, other
|
sign all Microsoft Windows version, of course, but to avoid a monopoly, other
|
||||||
executables were signed. The list is rather short because with each signature
|
executables were signed. The list is ought to be short (and unfortunately, it
|
||||||
and authorized software, the attack surface grows and the probability of a
|
is not) because with each signature and authorized software, the attack surface
|
||||||
vulnerability raises. Several were already found in the recent past (e.g.
|
grows and the probability of a vulnerability raises. Several were already found
|
||||||
CVE-2020-10713[^CVE-2020-10713], CVE-2022-34301[^CVE-2022-34301],
|
in the recent past (e.g. CVE-2020-10713[^CVE-2020-10713],
|
||||||
CVE-2022-34302[^CVE-2022-34302], CVE-2022-34303[^CVE-2022-34303].
|
CVE-2022-34301[^CVE-2022-34301], CVE-2022-34302[^CVE-2022-34302],
|
||||||
|
CVE-2022-34303[^CVE-2022-34303].
|
||||||
|
|
||||||
[^CVE-2020-10713]: [CVE-2020-10713](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713)
|
[^CVE-2020-10713]: [CVE-2020-10713](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713)
|
||||||
|
|
||||||
|
@ -110,15 +114,16 @@ Intel[^intelUpgrade] or Lenovo[^lenovoUpgrade].
|
||||||
|
|
||||||
[^lenovoUpgrade]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
|
[^lenovoUpgrade]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
|
||||||
|
|
||||||
Grub and the kernels are not directly authorized by Microsoft, as it would
|
Grub and the kernels are not directly authorized by Microsoft, as it would
|
||||||
require for each and every single version to be signed individually by
|
require for each and every single version to be signed individually by
|
||||||
Microsoft. Instead, a binary called Shim[^shim] was developed. This rather
|
Microsoft. Instead, a binary called Shim[^shim] was developed. This rather
|
||||||
small, auditable, innocuous-looking program is signed by Microsoft. Its role is
|
small, auditable, innocuous-looking program is signed by Microsoft. Its role is
|
||||||
basically that of a trojan horse. Indeed, its only purpose is to
|
basically that of a trojan horse (or a security pivot, depending on the way you
|
||||||
cryptographically verify the authenticity of any executable. However, this
|
look at it). Indeed, its only purpose is to cryptographically verify the
|
||||||
time, the list of public keys used to verify these executables is not directly
|
authenticity of any executable. However, this time, the list of public keys
|
||||||
under the control of Microsoft. These public keys are either built in Shim
|
used to verify these executables is not directly under the control of
|
||||||
itself or stored in a EFI variable serving as a database.
|
Microsoft. These public keys are either built in Shim itself or stored in a EFI
|
||||||
|
variable serving as a database.
|
||||||
|
|
||||||
[^shim]: [shim source code](https://github.com/rhboot/shim)
|
[^shim]: [shim source code](https://github.com/rhboot/shim)
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue