You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the fde-tpm-sb tutorial -- I've tried it with a mix of "hey cool guide" and "sucks that it doesn't just do all this out of the box yet".
What tripped me up was that I've skipped the "Set up Secure Boot with your own keys" section -- after all, so the reasoning, even if I managed to keep my signing of my kernels perfectly safe, unless I do a lot of auditing myself, I'd only be signing blindly the kernels as are produced by Debian, and that is already done well by Debian's processes. But that was also the part where GRUB was moved out of the equation, so when the startup finally worked and I came to the late cleanups such as setting panic=0, I found that I could change the kernel command line in GRUB and then all is for naught (b/c init=/bin/sh just works).
To spare others the same pain (I'm being dramatic here -- I'm still joyful with how all this works!), some suggestions with no precise ideas on what works out best:
Split the bootup preliminaries (i.e. switching away from GRUB into something that will then be measured into the initial sealing of the key) from the doing-your-own-signatures
If that doesn't work, explain why own-signatures are important
Find a register that also measures the kernel command line arguments, so that while anyone can start things with init=/bin/sh (it's useful to have GRUB's features in that regard), they'll forfeit their register content and be left with a disk unlock prompt.
The text was updated successfully, but these errors were encountered:
Grub as configured in Debian stable measures all its commands, module commands and the kernel command line into register 8 as per 1. That may result in slightly more frequent needs to re-seal (I'd expect that to be on larger Grub updates), but it's easier to do than switching away from grub completely. Given there is no signature on the initrd, it may also be necessary to measure initrd, which Grub does into register 9 along with all other files it reads. That'd probably mean a password-full boot after every update that touches the kernel.
Grub as configured in Debian stable measures all its commands, module commands and the kernel command line into register 8 as per 1.
That's a nice feature! I have found this which documents what you are talking about but from the shim. If the UEFI measures the shim, the shim measures grub, and grub measures all it does, this should be as secure as the setup I describe. And it has the advantage of removing the need for at least half of the guide! The only downside is that we'd need to input the password after each update (and set up some kind of automatic resealing). It'd be nice if we could avoid that, to have an experience closer to Windows' BitLocker.
I'll try this setup some day, but I don't have much free time for the moment, so I can't give any time estimate ^^ I added a note at the beginning of the guide with a link to this issue.
Thanks for the fde-tpm-sb tutorial -- I've tried it with a mix of "hey cool guide" and "sucks that it doesn't just do all this out of the box yet".
What tripped me up was that I've skipped the "Set up Secure Boot with your own keys" section -- after all, so the reasoning, even if I managed to keep my signing of my kernels perfectly safe, unless I do a lot of auditing myself, I'd only be signing blindly the kernels as are produced by Debian, and that is already done well by Debian's processes. But that was also the part where GRUB was moved out of the equation, so when the startup finally worked and I came to the late cleanups such as setting panic=0, I found that I could change the kernel command line in GRUB and then all is for naught (b/c init=/bin/sh just works).
To spare others the same pain (I'm being dramatic here -- I'm still joyful with how all this works!), some suggestions with no precise ideas on what works out best:
The text was updated successfully, but these errors were encountered: