I’ll play devil’s advocate here. While it’s definitely bad that this is the default setting, I like the fact that they added these options to the usual secure boot configuration options, which aren’t so flexible. For example, it looks like they added an option to prompt the user if they want to boot an unsigned binary.
I don’t think Microsoft is currently doing it currently, but I seem to recall some versions of Windows 8 may have started nagging you if it detected secure boot was disabled. When functionality like this can be used in user-hostile ways, as secure boot so often is, having the ability to lie to the OS is a good thing. It’s a question of whether my machine is under my control, or someone else’s.
‘Silently skip verifying’ definitely shouldn’t be the default option though — this is very bad. I’d also recommend auditing whether this variable can be successfully modified from an OS — they could have easily messed up protecting it against modification by the OS.
The fact that this is even an option increases the number of attack surfaces of the system though. The “Custom” secure boot mode is there for users to be able to use their own keys to sign their kernel, but by default it just kills all security and just lies to the system about it.
This isn’t something I mentioned in the article, but this default also breaks GRUB. If you boot with this enabled, GRUB will complain that shim is not installed and it won’t boot anything.
Overall I don’t mind having this option. It has been also available in some older ASUS and MSI motherboards from 2013, but with more reasonable defaults.
For example, it looks like they added an option to prompt the user if they want to boot an unsigned binary.
This setting is broken. If you use a bootloader, you will only be able to confirm booting of the bootloader, you won’t be able to confirm the OS that the bootloader starts. You will get the dialog, but the input won’t work.
MSI didn’t really do much of their own work, they just exposed available EDK II settings.
When functionality like this can be used in user-hostile ways, as secure boot so often is, having the ability to lie to the OS is a good thing
Kind of. There’s no point having a thing telling the OS if secure boot is enabled because you can always lie. If you have a TPM then the secure boot measurements are fed into that and then the TPM will refuse to unlock keys (or will use the measurements as an input into a KDF so that you get a key, just not the right one) if you do not have the right trust chain. This is what makes hard disk encryption safe: if someone tampers with your kernel image then the TPM won’t disclose the key and so you can’t encrypt the OS. Technically, the OS might not know whether it has a valid secure boot chain, but it will definitely notice that decrypting the disk fails.
I’ll play devil’s advocate here. While it’s definitely bad that this is the default setting, I like the fact that they added these options to the usual secure boot configuration options, which aren’t so flexible. For example, it looks like they added an option to prompt the user if they want to boot an unsigned binary.
I don’t think Microsoft is currently doing it currently, but I seem to recall some versions of Windows 8 may have started nagging you if it detected secure boot was disabled. When functionality like this can be used in user-hostile ways, as secure boot so often is, having the ability to lie to the OS is a good thing. It’s a question of whether my machine is under my control, or someone else’s.
‘Silently skip verifying’ definitely shouldn’t be the default option though — this is very bad. I’d also recommend auditing whether this variable can be successfully modified from an OS — they could have easily messed up protecting it against modification by the OS.
The fact that this is even an option increases the number of attack surfaces of the system though. The “Custom” secure boot mode is there for users to be able to use their own keys to sign their kernel, but by default it just kills all security and just lies to the system about it.
This isn’t something I mentioned in the article, but this default also breaks GRUB. If you boot with this enabled, GRUB will complain that shim is not installed and it won’t boot anything.
Overall I don’t mind having this option. It has been also available in some older ASUS and MSI motherboards from 2013, but with more reasonable defaults.
This setting is broken. If you use a bootloader, you will only be able to confirm booting of the bootloader, you won’t be able to confirm the OS that the bootloader starts. You will get the dialog, but the input won’t work.
MSI didn’t really do much of their own work, they just exposed available EDK II settings.
Kind of. There’s no point having a thing telling the OS if secure boot is enabled because you can always lie. If you have a TPM then the secure boot measurements are fed into that and then the TPM will refuse to unlock keys (or will use the measurements as an input into a KDF so that you get a key, just not the right one) if you do not have the right trust chain. This is what makes hard disk encryption safe: if someone tampers with your kernel image then the TPM won’t disclose the key and so you can’t encrypt the OS. Technically, the OS might not know whether it has a valid secure boot chain, but it will definitely notice that decrypting the disk fails.