Remove unintentional unicode unbreakable spaces
This commit is contained in:
parent
e2a372f00a
commit
04eede28ee
1 changed files with 19 additions and 19 deletions
|
@ -66,11 +66,11 @@ 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
|
||||||
requiring medium security level (level 2 out of 4, 1 being the minimal
|
requiring medium security level (level 2 out of 4, 1 being the minimal
|
||||||
requirements and 4 being for highly secure systems). Meanwhile, using a Unified
|
requirements and 4 being for highly secure systems). Meanwhile, using a Unified
|
||||||
Kernel Image to bundle the Linux kernel with a initramfs into a single
|
Kernel Image to bundle the Linux kernel with a initramfs into a single
|
||||||
executable that can be verified by Secure Boot is only recommended[^R6] for
|
executable that can be verified by Secure Boot is only recommended[^R6] for
|
||||||
highly secure systems (security level 4 out of 4). No recommendation is ever
|
highly secure systems (security level 4 out of 4). No recommendation is ever
|
||||||
done about using one of the aforementioned integrity features to ensure
|
done about using one of the aforementioned integrity features to ensure
|
||||||
operating system integrity.
|
operating system integrity.
|
||||||
|
|
||||||
[^linuxguide]: no English version yet. [French version](https://www.ssi.gouv.fr/uploads/2019/02/fr_np_linux_configuration-v2.0.pdf)
|
[^linuxguide]: no English version yet. [French version](https://www.ssi.gouv.fr/uploads/2019/02/fr_np_linux_configuration-v2.0.pdf)
|
||||||
|
@ -84,7 +84,7 @@ level, and 45% even think that it should be a minimum requirement.
|
||||||
This article is a strong push-back against ANSSI "recommendation", and it
|
This article is a strong push-back against ANSSI "recommendation", and it
|
||||||
attempts to prove that it is not only useless but incoherent and misleading.
|
attempts to prove that it is not only useless but incoherent and misleading.
|
||||||
|
|
||||||
[^poll]: [Mastodon poll](https://infosec.exchange/@x_cli/109348532363333158)
|
[^poll]: [Mastodon poll](https://infosec.exchange/@x_cli/109348532363333158)
|
||||||
|
|
||||||
## Signature verification and default public keys
|
## Signature verification and default public keys
|
||||||
|
|
||||||
|
@ -98,21 +98,21 @@ in the recent past (e.g. CVE-2020-10713[^CVE-2020-10713],
|
||||||
CVE-2022-34301[^CVE-2022-34301], CVE-2022-34302[^CVE-2022-34302],
|
CVE-2022-34301[^CVE-2022-34301], CVE-2022-34302[^CVE-2022-34302],
|
||||||
CVE-2022-34303[^CVE-2022-34303].
|
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)
|
||||||
|
|
||||||
[^CVE-2022-34301]: [CVE-2022-34301](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34301)
|
[^CVE-2022-34301]: [CVE-2022-34301](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34301)
|
||||||
|
|
||||||
[^CVE-2022-34302]: [CVE-2022-34302](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34302)
|
[^CVE-2022-34302]: [CVE-2022-34302](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34302)
|
||||||
|
|
||||||
[^CVE-2022-34303]: [CVE-2022-34303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34303)
|
[^CVE-2022-34303]: [CVE-2022-34303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34303)
|
||||||
|
|
||||||
For this reason, many software still require that Secure Boot be deactivated,
|
For this reason, many software still require that Secure Boot be deactivated,
|
||||||
including firmware updates by some manufacturers, including
|
including firmware updates by some manufacturers, including
|
||||||
Intel[^intelUpgrade] or Lenovo[^lenovoUpgrade].
|
Intel[^intelUpgrade] or Lenovo[^lenovoUpgrade].
|
||||||
|
|
||||||
[^intelUpgrade]: [Intel UEFI Flash BIOS Update Instruction](https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/UEFI-Flash-BIOS-Update-Instructions.pdf)
|
[^intelUpgrade]: [Intel UEFI Flash BIOS Update Instruction](https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/UEFI-Flash-BIOS-Update-Instructions.pdf)
|
||||||
|
|
||||||
[^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
|
||||||
|
@ -125,7 +125,7 @@ used to verify these executables is not directly under the control of
|
||||||
Microsoft. These public keys are either built in Shim itself or stored in a EFI
|
Microsoft. These public keys are either built in Shim itself or stored in a EFI
|
||||||
variable serving as a database.
|
variable serving as a database.
|
||||||
|
|
||||||
[^shim]: [shim source code](https://github.com/rhboot/shim)
|
[^shim]: [shim source code](https://github.com/rhboot/shim)
|
||||||
|
|
||||||
Additionally, shim public key list can be altered by any user able to prove
|
Additionally, shim public key list can be altered by any user able to prove
|
||||||
"presence". This is the case of any user using the local console or using a BMC
|
"presence". This is the case of any user using the local console or using a BMC
|
||||||
|
@ -139,17 +139,17 @@ the system believe that Secure Boot was used to bootstrap security, while
|
||||||
untrusted code was ultimately run within the UEFI privileged mode.
|
untrusted code was ultimately run within the UEFI privileged mode.
|
||||||
|
|
||||||
Hence, thanks to shim, just about any signed or unsigned, trusted or untrusted
|
Hence, thanks to shim, just about any signed or unsigned, trusted or untrusted
|
||||||
executable can be validated by proxy by Secure Boot using Microsoft keys.
|
executable can be validated by proxy by Secure Boot using Microsoft keys.
|
||||||
|
|
||||||
And this conclusion signs (pun intended) the second incoherence in ANSSI
|
And this conclusion signs (pun intended) the second incoherence in ANSSI
|
||||||
recommendations. Indeed, they recommend replacing Microsoft keys by our own set
|
recommendations. Indeed, they recommend replacing Microsoft keys by our own set
|
||||||
of keys only for highly secure security level (R4). This means that all systems
|
of keys only for highly secure security level (R4). This means that all systems
|
||||||
with intermediate (2/4) and enhanced (3/4) security levels will have the false
|
with intermediate (2/4) and enhanced (3/4) security levels will have the false
|
||||||
sense of security of running Secure Boot while exposing themselves to attackers
|
sense of security of running Secure Boot while exposing themselves to attackers
|
||||||
capable of proving "presence".
|
capable of proving "presence".
|
||||||
|
|
||||||
For what it is worth, shim does provide a way secure all operations, including
|
For what it is worth, shim does provide a way secure all operations, including
|
||||||
disabling verification or enrolling new keys by setting a password on shim's
|
disabling verification or enrolling new keys by setting a password on shim's
|
||||||
MOK (Machine Owner Keys) Manager[^mokpass]. However, the feature is mostly
|
MOK (Machine Owner Keys) Manager[^mokpass]. However, the feature is mostly
|
||||||
unused because no Linux distro enables it (it requires user interaction during
|
unused because no Linux distro enables it (it requires user interaction during
|
||||||
the boot procedure) and system administrators often mistake the MOK Manager
|
the boot procedure) and system administrators often mistake the MOK Manager
|
||||||
|
@ -158,10 +158,10 @@ password that is asked when running mokutil commands (including `--import` and
|
||||||
`--disable-verification`), which is just a password used to confirm the will of
|
`--disable-verification`), which is just a password used to confirm the will of
|
||||||
the user in the MOK Manager. The author of this article failed to find a single
|
the user in the MOK Manager. The author of this article failed to find a single
|
||||||
tutorial or article discussing the necessity of setting a MOK Manager for a
|
tutorial or article discussing the necessity of setting a MOK Manager for a
|
||||||
Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a
|
Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a
|
||||||
MOK Manager password is recommended even for Windows administrators that have
|
MOK Manager password is recommended even for Windows administrators that have
|
||||||
no intention of ever running Linux, because MOK Manager is one of
|
no intention of ever running Linux, because MOK Manager is one of
|
||||||
the executables signed by the Microsoft keys.
|
the executables signed by the Microsoft keys.
|
||||||
|
|
||||||
[^mokpass]: The command is `mokutil --password`. Please consider using it.
|
[^mokpass]: The command is `mokutil --password`. Please consider using it.
|
||||||
|
|
||||||
|
@ -169,7 +169,7 @@ the executables signed by the Microsoft keys.
|
||||||
|
|
||||||
Since replacing the Microsoft keys and signing only authorized binaries (i.e.
|
Since replacing the Microsoft keys and signing only authorized binaries (i.e.
|
||||||
our own Unified Kernel Image and specifically not shim) is an option, why not
|
our own Unified Kernel Image and specifically not shim) is an option, why not
|
||||||
do that? It just requires that the system administrators replace the Secure
|
do that? It just requires that the system administrators replace the Secure
|
||||||
Boot keys. The question of who controls the private key and the signature
|
Boot keys. The question of who controls the private key and the signature
|
||||||
process is entirely up to whether the signed executable is altered or not by
|
process is entirely up to whether the signed executable is altered or not by
|
||||||
the system administrator. Distros could ship public keys and Unified Kernel
|
the system administrator. Distros could ship public keys and Unified Kernel
|
||||||
|
@ -186,7 +186,7 @@ First, as mentioned earlier, the only thing that we verified is that the
|
||||||
Unified Kernel Image is authentic. That kernel must then verify the operating
|
Unified Kernel Image is authentic. That kernel must then verify the operating
|
||||||
system to ensure that only verified software is run. This requires
|
system to ensure that only verified software is run. This requires
|
||||||
cryptographic verification of every single executable (binaries, scripts and
|
cryptographic verification of every single executable (binaries, scripts and
|
||||||
executable configuration files (because... yeah... that's a thing)) in the
|
executable configuration files (because... yeah... that's a thing)) in the
|
||||||
operating system. This can be achieved if we, at minimum, do the following:
|
operating system. This can be achieved if we, at minimum, do the following:
|
||||||
|
|
||||||
* use a read-only filesystem for our partitions containing executable code,
|
* use a read-only filesystem for our partitions containing executable code,
|
||||||
|
@ -222,7 +222,7 @@ of physical access or remote access through a BMC, what is? Is there a better
|
||||||
solution?
|
solution?
|
||||||
|
|
||||||
Well, to the best of the author knowledge, there is one: using a TPM. Using a
|
Well, to the best of the author knowledge, there is one: using a TPM. Using a
|
||||||
TPM will not necessarily prevent an attacker from tainting the firmware. It
|
TPM will not necessarily prevent an attacker from tainting the firmware. It
|
||||||
will not necessarily prevent booting untrusted and unverified executables. What
|
will not necessarily prevent booting untrusted and unverified executables. What
|
||||||
a TPM can give us is the ability to unseal a LUKS passphrase and get access to
|
a TPM can give us is the ability to unseal a LUKS passphrase and get access to
|
||||||
user data if and only if the cryptographically verified right version of UEFI
|
user data if and only if the cryptographically verified right version of UEFI
|
||||||
|
|
Loading…
Reference in a new issue