-
-
Notifications
You must be signed in to change notification settings - Fork 185
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
Add export CONFIG_AUTO_BOOT_TIMEOUT=5
to all board configs
#1441
Comments
@3hhh can you enable restricted boot and test how you you would want to do this? Recent purism merge add those possibilities, just would need a use case and a matching PR |
Restricted boot stops attacker to get to recovery shell and flash. And if one does, counter changes and Totp is wiped. Check it out |
Autoboot could be activated but would stop you at TPM disk unlock key? |
Otherwise autoboot would just kexec to OS which prompts the disk decryption password. The whole idea of heads is to type that passphrase in a trusted environment, not the OS. Waiting for your use case in which default boot should boot securely aftet timeout |
Hm I'v never used heads for that. Can I not consider the OS kernel trusted once it was verified?
A few use cases:
|
@3hhh I'm not sure I understand the concern here. You would trust kernel+initrd+boot parameters from preboot environment (heads) only but not booting into it? |
On 7/17/23 00:12, tlaurion wrote:
> Otherwise autoboot would just kexec to OS which prompts the disk decryption password. The whole idea of heads is to type that passphrase in a trusted environment, not the OS.
>
> Hm I'v never used heads for that. Can I not consider the OS kernel trusted once it was verified?
@3hhh I'm not sure I understand the concern here. You would trust it from preboot environment?
Yes, I do, if it was verified by heads before. Your comment indicated that it couldn't be trusted even if it was verified (= checksum checked) by heads. I was just curious why that should be the case. Maybe however we misunderstood each other, idk.
|
Two main features have been added through #1419 which might interest you here: Restricted Boot and Basic Boot modes.
I think I get where the confusion stems
So yet again, I'm not sure what would be the advantage here of adding autoboot (GRUB_TIMEOUT) to Restricted Boot or normal Heads boot. But if I understand your need correctly, what you want for your use case is to enable usb keyboard support, that is, packing USB HID kernel driver as a module and have that module loaded at boot so that you can type your TPM disk decryption key through a USB keyboard? Here are differences between normal, non-USB-HID enabled board config and USB HID enabled board config:
With those notions in the background, i'll reply inline below:
Enable usb keyboard for your board config as explaned above.
That would be Basic Boot without any tampering detection
Server normally offers BMC and Heads configs already deal with that. It would be either TOTP or HOTP, where TOTP permits to verify the code remotely and where USB Security dongle is connected on the motherboard to permit detached signature on OS upgrades. BMC in that case offers a serial console to Heads shell, and permits here again to type TPM disk decryption key passphrase in the firmware and not the OS. I guess there too, you could want to use Basic Mode or come with some kind of alternative remote attestation mechanisms to make sure everything is as expected (and verified externally) prior of typing your Disk Recovery Key passphrase in LUKS slot 0 key? TLDR: Autoboot is currently only supported on Basic Boot, and is basically Heads without security features. Having Restricted Boot with autoboot, as of today, doesn't make sense to me unless something else is implemented. I do not see a case where Autoboot could work, unless wewould totally trust Heads to unseal TPM disk unlock key without asking the user for any passphrase. That is, just like TPMTOTP is unsealed to produce HOTP/TOTP today, and would be some kind of Microsoft equivalent of bitlocker which doesn't "authenticate" the user, but only firmware and /boot integrity to boot into the OS. In that scenario, dractu recovery shell could be used to DoS the system. Just like today, without enabling Restricted Boot, an attacker can abuse of the Recovery Shell to do such DoS attack on the system (wipe disk, wipe TPM etc). So, if I get what you would want:
@3hhh Am I getting this right? |
On 7/17/23 18:12, tlaurion wrote:
TLDR: Autoboot is currently only supported on Basic Boot, and is basically Heads without security features. Having Restricted Boot with autoboot, as of today, doesn't make sense to me unless something else is implemented. I do not see a case where Autoboot could work, unless wewould totally trust Heads to unseal TPM disk unlock key without asking the user for any passphrase.
I think this is where the confusion stems from: I do not use a TPM disk unlock key. I use heads to verify /boot incl. initrd and then type the luks password at initrd.
I believe you said that this has worse security properties than using the TPM unlock, but I currently don't understand the difference. The only minor advantage I see is in restricted boot, where an attacker couldn't boot the OS at all (assuming s/he doesn't want to remove the disk, which takes ~15s on my machine).
I agree a timeout doesn't make sense with a TPM disk unlock key as you'll have to type the TPM password anyway.
Imho it makes sense for people who use the standard initrd luks prompt - even in restricted & normal boot.
Btw thank you very much for the link to basic boot! That'll indeed solve my use case for the test machine. :-)
|
I just tested basic boot on my test machine and it indeed seems to work. :-) It could use a timeout as well though. ;-) |
@3hhh sorry I didn't get back to you and now doing so while away of keyboard. Take a look at purism boards which have a timeout implemented AFAIK which is looked for in code. |
With Basic mode enabled, that is https://github.com/osresearch/heads/blob/6e31163121d1d600047df859844ab8408cc53d2a/boards/librem_14/librem_14.config#L42 |
Hm interesting. Looks like I guess then my request would be to set it to a reasonable value by default for all boards. Currently it's only enabled for Librem boards. Alternatively make it possible to edit it from the heads UI. |
Right, if HOTP dongle is connected and returns success. And otherwise if Basic mode enabled without validating anything. |
On 8/21/23 16:09, tlaurion wrote:
> Hm interesting. Looks like `CONFIG_AUTO_BOOT_TIMEOUT` is around for a long time - even for non-basic boot.
>
> I guess then my request would be to set it to a reasonable value by default for all boards. Currently it's only enabled for Librem boards. Alternatively make it possible to edit it from the heads UI.
Right, if HOTP dongle is connected and returns success. And otherwise if Basic mode enabled without validating anything.
Yes, these are exactly the two use cases I wanted covered. :-)
|
GRUB_TIMEOUT
or a similar optionexport CONFIG_AUTO_BOOT_TIMEOUT=5
to all board configs
@JonathonHall-Purism and what about having this timeout being automatic without it needing to be defined under board configs? Seems like if hotp good, we could go default boot just by changing that? |
I'd support changing the default behavior to automatically boot after 5 seconds 👍 It'd still be nice to keep the variable around - I know some of our users have requested shorter or longer times, so it'd be nice to add this as an actual config-gui setting (which I have on my to-do list for next release). So we could either change "empty" to mean "5 seconds", or write out a default value of 5 in /etc/config (if overriding to 'empty' should still mean 'don't automatically boot'). |
So we could either change "empty" to mean "5 seconds"
Negative might mean infinite then. However IIRC bash uses 64 Bit Integers which should be sufficiently close to infinite for most users...
On a side note, I'd vote more for 3s than 5s as from my experience 3s is the usual maximum time frame I need to react to something on my screen, whereas 5s is long enough to get annoyed about the timeout.
Anyway 5s is still way better than infinite imho. ;)
|
Thanks for the implementation! I can confirm that it works. Tested version: |
Cool, thanks for following up @3hhh ! |
Is your feature request related to a problem? Please describe.
heads doesn't start the boot process without user interaction.
Describe the solution you'd like
Add an option like
GRUB_TIMEOUT
to execute the default boot after some time, if that's defined and all verifications succeed.Additional context
I'd also like an option to boot after that timeout even if verification fails as that would help with testing.
However imho such an option breaks the heads security model as an attacker could simply enable it and then lure the user into auto-booting.EDIT: After giving it some more thought, I believe that such an option should be possible as an attacker can modify the firmware any way s/he wants anyway, The user will still have to manually check the HOTP/TOTP dongle to make sure that doesn't happen.
The text was updated successfully, but these errors were encountered: