3 ms·

do you have any more details. My first thought is "how simple" then "what am I missing"?

by lifeisstillgood 5y ago

lugged 5y ago
(slightly) slower boot time. Risk of data loss if your USB fails, more complicated backup procedures.
- SkyMarshal 5y ago
  Yes, you should use a higher quality USB drive for this, or possibly an SLC NAND one with high write endurance. And make a backup copy or two and store them in faraday bags in a safe.
  - deckard1 5y ago
    you're only going to write to the USB drive when you upgrade your kernel. all these worries are completely overblown. I've been using USB boot method for close to 10 years now. It's just another folder/mountpoint to backup along with your normal backup.
    - SkyMarshal 5y ago
      Anecdote != data. And unlike the other folders, if you lose this one you lose the whole system. And it's not just writes we care about, but bit flips for any reason.
      - deckard1 5y ago
        > Anecdote != data Thank you Captain Obvious. > And unlike the other folders, if you lose this one you lose the whole system Yeah, that's how encryption works. > but bit flips for any reason Way to move the goalposts. Your typical laptop/desktop does not have ECC RAM. You're also not using mirrored ZFS anyway. So not only will you never detect corruption, but you have no way to correct it either. Which, again, is totally overkill for the average user.
        SkyMarshal 5y ago
        > Way to move the goalposts. If your entire system is vulnerable to a single bit flip and you don't care then, you may be on the wrong website. > Your typical laptop/desktop does not have ECC RAM. You're also not using mirrored ZFS anyway. So not only will you never detect corruption, but you have no way to correct it either. This is HN, not your typical computer user's website. My personal desktop workstations use both registered ECC and mirrored ZFS (along with immutable reproducible builds, among other things to enhance system integrity and reliability). And I have no compunction whatsoever about recommending on this site that people use cheap and easy methods to safeguard against LUKS header corruption, like backup USBs and faraday bags. That's an extremely cheap form of risk management that could prevent loss of your entire hard drive due to a single bit flip. If I were recommending something prohibitively expensive relative to the potential losses, your objections might be reasonable, but I'm not. > Which, again, is totally overkill for the average user. Again, this isn't a site for the average user, expect folks here to practice and recommend higher standards for computer system management.
- pengaru 5y ago
  There's nothing hard to replace in a kernel or initrd, it's just a matter of going back to the trusted source you originally used.
mkj 5y ago
Have to lug a usb stick around with you and guard it 24/7 for equivalent security?
- SkyMarshal 5y ago
  Not necessarily. If this is for a desktop computer you can just leave the USB plugged in and the computer running, as normal. The threat model isn’t too different between that and a normal home/office computer - in both cases you have to trust the physical security of your home/office. For a laptop, you’re already lugging it around anyway, just remove the USB drive whenever you shut it down.
- pengaru 5y ago
  I use a datatraveler 2000 to store my kernel+initrd, only inconvenience is having to unlock and insert it whenever I boot my laptop. If I use the keyfile feature, the dt2000 boot will automatically unlock my FDE, making the inconvenience a bit of a wash with arguably improved overall security. It's also nice that I can unlock the dt2000 in private or otherwise independently from the laptop, since it has a battery. Think bathroom break to unlock, insert to boot on return kind of thing. It also supports a read-only mode, requiring switching to writable whenever updating the kernel/initrd.
- WaitWaitWha 5y ago
  Or, instead of a USB, you have a remote, networked, secure repository that behaves as such.
nsajko 5y ago
Firstly, you'd probably want to make backups of the USB device with the initrd, in case one of them fails. To mount the decrypted disk during boot, it's necessary to make the kernel aware of the fact that it's something that should be mounted. There are several ways to do this, two of which are: 1. The most preferable way, I think, would be to use something like kpartx from multipath-tools. Kpartx is a very simple C program, and device mapper is used directly in that case. You could also use partprobe. So the command is something like `kpartx -a disk` or `partprobe disk`. 2. Another option is to use LVM, like described here: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti... (there are also other encryption options described there). Using LVM is a solution that works more out-of-the-box, but, of course, then you always depends on LVM, which may not be something you want.

do you have any more details. My first thought is "how simple" then "what am I missing"?

lugged 5y ago

(slightly) slower boot time. Risk of data loss if your USB fails, more complicated backup procedures.

SkyMarshal 5y ago
Yes, you should use a higher quality USB drive for this, or possibly an SLC NAND one with high write endurance. And make a backup copy or two and store them in faraday bags in a safe.
- deckard1 5y ago
  you're only going to write to the USB drive when you upgrade your kernel. all these worries are completely overblown. I've been using USB boot method for close to 10 years now. It's just another folder/mountpoint to backup along with your normal backup.
  - SkyMarshal 5y ago
    Anecdote != data. And unlike the other folders, if you lose this one you lose the whole system. And it's not just writes we care about, but bit flips for any reason.
    - deckard1 5y ago
      > Anecdote != data Thank you Captain Obvious. > And unlike the other folders, if you lose this one you lose the whole system Yeah, that's how encryption works. > but bit flips for any reason Way to move the goalposts. Your typical laptop/desktop does not have ECC RAM. You're also not using mirrored ZFS anyway. So not only will you never detect corruption, but you have no way to correct it either. Which, again, is totally overkill for the average user.
      - SkyMarshal 5y ago
        > Way to move the goalposts. If your entire system is vulnerable to a single bit flip and you don't care then, you may be on the wrong website. > Your typical laptop/desktop does not have ECC RAM. You're also not using mirrored ZFS anyway. So not only will you never detect corruption, but you have no way to correct it either. This is HN, not your typical computer user's website. My personal desktop workstations use both registered ECC and mirrored ZFS (along with immutable reproducible builds, among other things to enhance system integrity and reliability). And I have no compunction whatsoever about recommending on this site that people use cheap and easy methods to safeguard against LUKS header corruption, like backup USBs and faraday bags. That's an extremely cheap form of risk management that could prevent loss of your entire hard drive due to a single bit flip. If I were recommending something prohibitively expensive relative to the potential losses, your objections might be reasonable, but I'm not. > Which, again, is totally overkill for the average user. Again, this isn't a site for the average user, expect folks here to practice and recommend higher standards for computer system management.
pengaru 5y ago
There's nothing hard to replace in a kernel or initrd, it's just a matter of going back to the trusted source you originally used.

mkj 5y ago

Have to lug a usb stick around with you and guard it 24/7 for equivalent security?

SkyMarshal 5y ago
Not necessarily. If this is for a desktop computer you can just leave the USB plugged in and the computer running, as normal. The threat model isn’t too different between that and a normal home/office computer - in both cases you have to trust the physical security of your home/office. For a laptop, you’re already lugging it around anyway, just remove the USB drive whenever you shut it down.
pengaru 5y ago
I use a datatraveler 2000 to store my kernel+initrd, only inconvenience is having to unlock and insert it whenever I boot my laptop. If I use the keyfile feature, the dt2000 boot will automatically unlock my FDE, making the inconvenience a bit of a wash with arguably improved overall security. It's also nice that I can unlock the dt2000 in private or otherwise independently from the laptop, since it has a battery. Think bathroom break to unlock, insert to boot on return kind of thing. It also supports a read-only mode, requiring switching to writable whenever updating the kernel/initrd.
WaitWaitWha 5y ago
Or, instead of a USB, you have a remote, networked, secure repository that behaves as such.

nsajko 5y ago

Firstly, you'd probably want to make backups of the USB device with the initrd, in case one of them fails. To mount the decrypted disk during boot, it's necessary to make the kernel aware of the fact that it's something that should be mounted. There are several ways to do this, two of which are: 1. The most preferable way, I think, would be to use something like kpartx from multipath-tools. Kpartx is a very simple C program, and device mapper is used directly in that case. You could also use partprobe. So the command is something like `kpartx -a disk` or `partprobe disk`. 2. Another option is to use LVM, like described here: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti... (there are also other encryption options described there). Using LVM is a solution that works more out-of-the-box, but, of course, then you always depends on LVM, which may not be something you want.