Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider separating out the "own keys" topic #9

Open
chrysn opened this issue Feb 19, 2024 · 2 comments
Open

Consider separating out the "own keys" topic #9

chrysn opened this issue Feb 19, 2024 · 2 comments

Comments

@chrysn
Copy link

chrysn commented Feb 19, 2024

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.
@chrysn
Copy link
Author

chrysn commented Feb 26, 2024

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.

@blastrock
Copy link
Owner

blastrock commented Mar 10, 2024

Hi,

Thanks for your feedback!

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 again for the discovery!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants