5 ms·

Does this matter? I once went through the waste of time of getting /boot encrypted. Would rather avoid needless pain.

• guipsp 5y ago
  It matters for deniability. Whether this matters for you or not depends on your use case.
  • geofft 5y ago
    What does a laptop with a bunch of random data on its disk and a lot of evidence of use (grime, worn keys, etc.) let you deny that the same laptop with a generic Linux boot partition followed by random data does not let you deny?
    • nsajko 5y ago
      Let's put it this way: say you want to prevent somebody from getting the data on a disk. Wouldn't writing random data over the entire disk be a good idea?
      • cmurf 5y ago
        blkdiscard /dev/nvme0n1 No need to write anything. Better would be to use nvme tools to securely erase it ("format" is the terminology used)
        • lugged 5y ago
          The idea is to give you the plausible deniability, you can tell the cops you wiped it with random data, there is no password. Your flash drive can't then be used as evidence that you haven't wiped it yet. The initrd on the drive would be evidence you haven't wiped the drive. Whether that gets you out of a jam and not in trouble for destroying evidence is another question.
          • throwaway41597 5y ago
            So have one drive with FDE and a USB drive with /boot but in no explicit way configured to boot the first drive? Or maybe a better setup is an internal drive with /boot and a system stripped from sensitive files then somewhere in the drive an hidden partition (not sure how to avoid the vanilla OS overwriting the hidden partition), then you can either boot the vanilla OS or map the hidden partition and boot from it.
• nsajko 5y ago
  It matters for deniability and for reliability. If you have LUKS, you really don't want to corrupt the header.
• sillystuff 5y ago
  For servers that you need to unlock remotely, you will need to leave /boot unencrypted. But, for things like a laptop, grub has supported encrypted /boot for a while now (and it works well). But, the release versions still only support luks v1 (it was good enough for all those years, probably still fine for most folks mostly just worried about their laptop getting misplaced / stolen). add to /etc/default/grub to enable encrypted /boot support: GRUB_ENABLE_CRYPTODISK=y After encrypting /boot, you don't need anything besides ensuring that the less than 2MB of unencrypted grub bootloader that is installed before the first partition on BIOS machines or into /boot/uefi on uefi machines is verified to ensure that 100% of the boot process is trusted (and all your data too since 100% of the disk is encrypted except for < 2MB of boot loader). A simple way (if your threat model isn't mosad/nsa) is just checking a hash of this tiny bit of data whenever something sketchy has occurred with your laptop e.g., it is left unattended with airport security. Just boot from a thumb drive, and check the hash (it will only change if you e.g., change your filesystem type or grub gets patches). If OK, then boot is still trusted (at least what is on disk; if threat model makes you a possible target for hardware manipulation this nor Pottering's proposal will help you). Nice if this simple check of less than 2MB could be automated, but not in a complex and fragile way that removes freedom from the nominal owner of the computer as Pottering is suggesting.