My current setup (LUKS+LVM) requires an initrd/initramfs image in order to boot the system. Also I recently configured Secure Boot with my own keys and everything works well.
I noticed that the initrd/initramfs image isn't signed compared to the kernel or rEFInd binaries. Is there a way to force the system to sign/verify this file, or can't this be done? Also, if it's impossible, is there any sense in using Secure Boot in such setup? Someone could, for instance, place anything in the initrd/initramfs image, which would be loaded without any control. Why the initrd/initramfs image isn't signed at all?
There are tools that can be loaded by the EFI/UEFI firmware directly. Should tools like MokManager or KeyTool be signed when you want to use Secure Boot? Or maybe would it be better not to sign them and set the supervisor password, which would allow to access the tools after typing the password (switching to non Secure Boot mode). Also, what about the EFIshell tool?
When I used mokutil to add linux distributions keys to the MOK database, they were added successfully, and I can see them when I issue: # mokutil --list-enrolled
But there's also the MokList variable that can be read via: # efi-readvar -v MokList Variable MokList has no entries
And it has no entries. What's the purpose of this variable? Shouldn't the keys be added to this variable via mokutil tool?
The debian's shim is signed this distribution's key, and when I typed the following command: # mokutil --import debian-uefi-ca.cer canonical-uefi-ca.cer
the debian cert entry in the MOK database appeared twice. It's the same key but it was doubled. If I imported only the canonical cert, then the debian entry would be just one. I know it's because the debian cert is embedded in the shim binary. But the question is how to add the debian cert without adding another distribution's cert or doubling the entry in the MOK database?
There's a cert repository[1] where certain certs are stored, but I noticed that there's Debian's cert missing. It can be found here[2]. Would you add it to this repo?
Secure Boot keys are used to sign EFI binaries. The initrd is not a Secure Boot binary, so signing it makes no sense. (Think of the initrd as a tiny filesystem image; signing it would be akin to signing your Linux root [/] filesystem.) Instead, under the Secure Boot model, the (signed) kernel is responsible for handling the security of everything it loads, whether those modules and binaries are stored in an initrd file or a regular filesystem on a partition or logical volume. That said, how much post-kernel (or even post-boot-loader) authentication occurs depends on the boot loader, the kernel, and more. Especially older or less-security-conscious Linux distributions might not authenticate anything beyond the kernel. You'll need to dig into details for the current version of your specific distribution to learn how much is authenticated.
Yes, MokManager, KeyTool, and the EFI shell not only should be signed; they must be signed, at least when Secure Boot is active. If Secure Boot is active and you try to launch one of these tools from rEFInd (or in any other way), and if the tool is not signed, then it should not launch.
The mokutil and efi-readvar utilities have evolved considerably since the last time I looked at them in much depth, so I'm afraid I don't know the answer to this question.
Ditto.
The last time I checked, Debian had not released a Secure Boot key. I'll look into adding it to rEFInd's list. Thanks for the pointer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As for the signing EFI tools -- I've read about some security concerns where people don't want to sign tools like KeyTool or MokManager, because someone can use them without any control when they get access to the machine. Those people suggested to set the supervisor password for EFI, then when you want to use the tools, you simply go to the EFI settings, enter the pass, turn the Secure Boot mode off, and then boot and load the binaries. When you finish, you just enable Secure Boot again. Is this reasonable behavior or is it a little bit paranoic and it can have some implications when it comes to using tools like the KeyTool or MokManager?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's no such thing as 100% security; you must set the level for your perceived risk. Not signing the key-management tools and instead relying on firmware passwords might be appropriate for some high-security systems, but for the average single-user desktop or laptop, that measure would be overkill, IMHO. Somebody else might have another opinion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My current setup (LUKS+LVM) requires an initrd/initramfs image in order to boot the system. Also I recently configured Secure Boot with my own keys and everything works well.
I noticed that the initrd/initramfs image isn't signed compared to the kernel or rEFInd binaries. Is there a way to force the system to sign/verify this file, or can't this be done? Also, if it's impossible, is there any sense in using Secure Boot in such setup? Someone could, for instance, place anything in the initrd/initramfs image, which would be loaded without any control. Why the initrd/initramfs image isn't signed at all?
There are tools that can be loaded by the EFI/UEFI firmware directly. Should tools like MokManager or KeyTool be signed when you want to use Secure Boot? Or maybe would it be better not to sign them and set the supervisor password, which would allow to access the tools after typing the password (switching to non Secure Boot mode). Also, what about the EFIshell tool?
When I used
mokutil
to add linux distributions keys to the MOK database, they were added successfully, and I can see them when I issue:# mokutil --list-enrolled
But there's also the MokList variable that can be read via:
# efi-readvar -v MokList
Variable MokList has no entries
And it has no entries. What's the purpose of this variable? Shouldn't the keys be added to this variable via mokutil tool?
The debian's shim is signed this distribution's key, and when I typed the following command:
# mokutil --import debian-uefi-ca.cer canonical-uefi-ca.cer
the debian cert entry in the MOK database appeared twice. It's the same key but it was doubled. If I imported only the canonical cert, then the debian entry would be just one. I know it's because the debian cert is embedded in the shim binary. But the question is how to add the debian cert without adding another distribution's cert or doubling the entry in the MOK database?
There's a cert repository[1] where certain certs are stored, but I noticed that there's Debian's cert missing. It can be found here[2]. Would you add it to this repo?
1: https://sourceforge.net/p/refind/code/ci/master/tree/keys/
2: https://dsa.debian.org/secure-boot-ca
/
] filesystem.) Instead, under the Secure Boot model, the (signed) kernel is responsible for handling the security of everything it loads, whether those modules and binaries are stored in an initrd file or a regular filesystem on a partition or logical volume. That said, how much post-kernel (or even post-boot-loader) authentication occurs depends on the boot loader, the kernel, and more. Especially older or less-security-conscious Linux distributions might not authenticate anything beyond the kernel. You'll need to dig into details for the current version of your specific distribution to learn how much is authenticated.mokutil
andefi-readvar
utilities have evolved considerably since the last time I looked at them in much depth, so I'm afraid I don't know the answer to this question.As for the signing EFI tools -- I've read about some security concerns where people don't want to sign tools like KeyTool or MokManager, because someone can use them without any control when they get access to the machine. Those people suggested to set the supervisor password for EFI, then when you want to use the tools, you simply go to the EFI settings, enter the pass, turn the Secure Boot mode off, and then boot and load the binaries. When you finish, you just enable Secure Boot again. Is this reasonable behavior or is it a little bit paranoic and it can have some implications when it comes to using tools like the KeyTool or MokManager?
There's no such thing as 100% security; you must set the level for your perceived risk. Not signing the key-management tools and instead relying on firmware passwords might be appropriate for some high-security systems, but for the average single-user desktop or laptop, that measure would be overkill, IMHO. Somebody else might have another opinion.