data1701d (He/Him)

“Life forms. You precious little lifeforms. You tiny little lifeforms. Where are you?”

- Lt. Cmdr Data, Star Trek: Generations

  • 51 Posts
  • 491 Comments
Joined 11 months ago
cake
Cake day: March 7th, 2024

help-circle



  • (Note: Anything I say could be B.S. I could be completely misunderstanding this.)

    Clevis isn’t too difficult to set up - Arch Wiki documents the process really well. I’ve found it works better with dracut that mkinitcpio.

    As for PCR registers (which I haven’t set up yet but should), what I can tell, it sets the hash of the boot partition and UEFI settings in the TPM PCR register so it can check for tampering on the unencrypted boot partition and refuse to give the decryption keys if it does. That way, someone can’t doctor your boot partition and say, put the keys on a flash drive - I think they’d have to totally lobotomize your machine’s hardware to do it, which only someone who has both stolen your device and has the means/budget to do that would do.

    You do need to make sure these registers are updated every kernel update, or else you’ll have to manually enter the LUKS password the next boot and update it then. I’m wondering if there’s a hook I can set up where every time the boot partition is updated, it updates PCR registers.













  • I don’t do it for my desktop because 1) I highly doubt my desktop would get stolen. 2) I installed Linux before I was aware of encryption, and don’t have any desire to do a reinstall on my desktop at this time.

    For my laptop, yes, I do (with exception of the boot partition), since it would be trivial to steal and this is a more recent install. I use clevis to auto-unlock the drive by getting keys from the TPM. I need to better protect myself against evil maids, though - luckily according to the Arch Wiki Clevis supports PCR registers.




  • I wouldn’t necessarily say that - Debian and FreeBSD releases have roughly the same support lifespan, meaning if installed on release day, you’d get a few (~5 years) years of support without major upgrades.

    I’d say both systems have a high chance of success at upgrading to the immediate next version, so that becomes maybe 7 or 8 years when adding the years of support left on the now older immediate next version.

    For a second immediate next upgrade, you might be right that a BSD has a better chance of surviving.

    I wouldn’t know about Open SD, though, as they operate on point releases and I don’t know to what extent they prevent breaking changes.