5 ms·

I wonder which of these tools Ubuntu is using - since they enabled TPM-backed encryption (Bitlocker-style) in 23.10. https://ubuntu.com/blog/tpm-backed-full-dis

I wonder which of these tools Ubuntu is using - since they enabled TPM-backed encryption (Bitlocker-style) in 23.10. https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-coming-to-ubuntu https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-c... I am not a huge fan of relying on this, I cannot recall numer of times where I had to recover my files from live USB or by plugging my drive into another PC - both of which will get difficult to do when my true password sits in TPM on the (potentially bricked) motherboard. But I guess that if it can be used in addition to regular password (e.g. use regular password when TPM is missing, use PIN if it works) then it's fine

Manfred 3y ago
Do you prefer restoring from the original drive instead of a backup because it's faster?
- magicalhippo 3y ago
  I use a daily full-disk backup on Windows[1], this has allowed me to be back up and running within the hour the few cases my disk died. What's a good alternative for Linux? [1]: Acronis TrueImage, but there are others.
  - jeroenhd 3y ago
    With modern file systems like BTRFS you could take a(n incremental) snapshot and send that over the network using btrfs send. Filesystems without snapshots can't be disk cloned that easily, but tools like Timeshift will try to replicate snapshot behaviour using hardlinks, so I assume backups of Timeshift snapshots should also suffice. Timeshift can be configured in various ways, including making daily snapshots. I mostly use it for periodic snapshots and snapshots taken before the package manager runs (as a poor man's System Restore alternative). I don't think Timeshift supports automatically sending snapshots just yet. For that, you'd need to set up a cronjob or systemd timer.
    - o11c 3y ago
      Last time I tried to replace my `rsync` backups, `btrfs send` had grave limitations - something like "you can't actually use the destination filesystem for anything other than the one computers backups" I think?
      - jeroenhd 3y ago
        btrfs receive has some limitations for sure. I don't think having the volume mounted is a problem, but during the transfer the snapshot is read/write. If you modify the volume, subsequent differential updates will fail. If you have some other process messing with the snapshot being received, you also risk messing up the send/receive. There are also limitations w.r.t. the way the volume is mounted; if you alter the default mount point or mounted a subvolume somewhere deep in the chain, receive will also fail. If you have a BTRFS volume on a server that exists purely to receive backups and separate the subvolumes sufficiently (i.e. using specific subvolumes for the different backed up devices), I don't think send/receive should be a problem. I wouldn't back up to the root partition of a running system, I think a dedicated data volume makes a lot more sense design-wise.
- zeta0134 3y ago
  Often I want to collect a very small number of files that I was working on which are newer than the last complete backup
INTPenis 3y ago
Also, correct me if I'm wrong, but TPM shifts the password input prompt from traditionally LUKS during boot, to your XDM or whatever display manager you're using? And I seem to recall a recent vulnerability where people were able to bypass the display manager login on some graphical desktop Linux distro. I just don't feel comfortable shifting the threat to this part of the OS, because desktop Linux has not had the extensive testing required yet. It reminds me of when I was in school and you could bypass NT4 or Windows 98 logins by mashing the Enter key or doing weird user input combinations. Basically manually fuzzing. If TPM only adds convenience then I'd prefer to continue entering my LUKS password, and my login password, separately.
- proto_lambda 3y ago
  If you rely only on TPM for key storage, yes, the disk is unlocked automatically and any sufficiently broken userspace application you can get your hands on will let you access it. You can still combine TPM+passphrase/PIN though, at the cost of having to enter it at boot.
  - worksonmine 3y ago
    > at the cost of having to enter it at boot Isn't this the entire point of full disk encryption? You mention cost, but what is even the benefit of encryption that's unlocked by just booting?
    - proto_lambda 3y ago
      With properly functioning secure boot and no bugs in the entire software stack, it doesn't matter if the disk is decrypted automatically, since you can't access the system without OS-level authentication. If you tried to replace system files to let you get in anyway, the secure boot measurements would no longer match up and the decryption fails entirely.
      - worksonmine 3y ago
        I use a very long and inconvenient password for LUKS, and a simpler one for login and root. My lock screen is more a convenience in a trusted environment and not security. The TPM only solution sounds like it would require my very long password every time I leave my desk to get coffee.
jeroenhd 3y ago
Ubuntu's implementation will also allow you to export a backup passphrase in case the TPM gets zapped (by a firmware update for example) after which you can re-enroll. Annoyingly, this is a random 16 byte value that's translated into a numeric string that only Ubuntus's cryptsetup wrapper seems to use. You need to convert it into an actual key if you want to re-enroll your TPM or add a key file/passphrase to another slot. If you don't back up the recovery key, your data is lost.
- poettering 3y ago
  systemd has a similar logic, i.e. a recovery key concept, but we made sure you can type it in wherever a LUKS password would work too, even on systems where systemd is not available but LUKS ist. The recovery key is output in yubikey's modhex alphabet which means you can type it in on many keyboards even without setting a keymap first, and will work. We also output it as qr code, in case you want to scan it off. All on all it should be as robust as a recovery key could be.
  - immibis 3y ago
    That's a highly unusual attitude for systemd. Most of the systemd architecture requires you to run systemd for everything if you use it at all. What changed?
    - poettering 3y ago
      Nothing changed. You are just a victim of FUD on the Internet, my friend. That's all.
      - immibis 3y ago
        Why does this remind me of something a Bitcoin or Gamestop fanatic would say?
  - generalizations 3y ago
    Oh cool. Does that mean the TPM key is set up to use one of the LUKS key slots?
poettering 3y ago
To my knowledge Ubuntu does not use the TPM2 PCR logic systemd provides at all, but their own.
egberts1 3y ago
Shifting PIN to an XDM? Does anyone remember the good ol' days of hitting spaces 127 times at a SunOS "login:" prompt to gain its root shell?

Manfred 3y ago

Do you prefer restoring from the original drive instead of a backup because it's faster?

magicalhippo 3y ago
I use a daily full-disk backup on Windows[1], this has allowed me to be back up and running within the hour the few cases my disk died. What's a good alternative for Linux? [1]: Acronis TrueImage, but there are others.
- jeroenhd 3y ago
  With modern file systems like BTRFS you could take a(n incremental) snapshot and send that over the network using btrfs send. Filesystems without snapshots can't be disk cloned that easily, but tools like Timeshift will try to replicate snapshot behaviour using hardlinks, so I assume backups of Timeshift snapshots should also suffice. Timeshift can be configured in various ways, including making daily snapshots. I mostly use it for periodic snapshots and snapshots taken before the package manager runs (as a poor man's System Restore alternative). I don't think Timeshift supports automatically sending snapshots just yet. For that, you'd need to set up a cronjob or systemd timer.
  - o11c 3y ago
    Last time I tried to replace my `rsync` backups, `btrfs send` had grave limitations - something like "you can't actually use the destination filesystem for anything other than the one computers backups" I think?
    - jeroenhd 3y ago
      btrfs receive has some limitations for sure. I don't think having the volume mounted is a problem, but during the transfer the snapshot is read/write. If you modify the volume, subsequent differential updates will fail. If you have some other process messing with the snapshot being received, you also risk messing up the send/receive. There are also limitations w.r.t. the way the volume is mounted; if you alter the default mount point or mounted a subvolume somewhere deep in the chain, receive will also fail. If you have a BTRFS volume on a server that exists purely to receive backups and separate the subvolumes sufficiently (i.e. using specific subvolumes for the different backed up devices), I don't think send/receive should be a problem. I wouldn't back up to the root partition of a running system, I think a dedicated data volume makes a lot more sense design-wise.
zeta0134 3y ago
Often I want to collect a very small number of files that I was working on which are newer than the last complete backup

INTPenis 3y ago

Also, correct me if I'm wrong, but TPM shifts the password input prompt from traditionally LUKS during boot, to your XDM or whatever display manager you're using? And I seem to recall a recent vulnerability where people were able to bypass the display manager login on some graphical desktop Linux distro. I just don't feel comfortable shifting the threat to this part of the OS, because desktop Linux has not had the extensive testing required yet. It reminds me of when I was in school and you could bypass NT4 or Windows 98 logins by mashing the Enter key or doing weird user input combinations. Basically manually fuzzing. If TPM only adds convenience then I'd prefer to continue entering my LUKS password, and my login password, separately.

proto_lambda 3y ago
If you rely only on TPM for key storage, yes, the disk is unlocked automatically and any sufficiently broken userspace application you can get your hands on will let you access it. You can still combine TPM+passphrase/PIN though, at the cost of having to enter it at boot.
- worksonmine 3y ago
  > at the cost of having to enter it at boot Isn't this the entire point of full disk encryption? You mention cost, but what is even the benefit of encryption that's unlocked by just booting?
  - proto_lambda 3y ago
    With properly functioning secure boot and no bugs in the entire software stack, it doesn't matter if the disk is decrypted automatically, since you can't access the system without OS-level authentication. If you tried to replace system files to let you get in anyway, the secure boot measurements would no longer match up and the decryption fails entirely.
    - worksonmine 3y ago
      I use a very long and inconvenient password for LUKS, and a simpler one for login and root. My lock screen is more a convenience in a trusted environment and not security. The TPM only solution sounds like it would require my very long password every time I leave my desk to get coffee.

jeroenhd 3y ago

Ubuntu's implementation will also allow you to export a backup passphrase in case the TPM gets zapped (by a firmware update for example) after which you can re-enroll. Annoyingly, this is a random 16 byte value that's translated into a numeric string that only Ubuntus's cryptsetup wrapper seems to use. You need to convert it into an actual key if you want to re-enroll your TPM or add a key file/passphrase to another slot. If you don't back up the recovery key, your data is lost.

poettering 3y ago
systemd has a similar logic, i.e. a recovery key concept, but we made sure you can type it in wherever a LUKS password would work too, even on systems where systemd is not available but LUKS ist. The recovery key is output in yubikey's modhex alphabet which means you can type it in on many keyboards even without setting a keymap first, and will work. We also output it as qr code, in case you want to scan it off. All on all it should be as robust as a recovery key could be.
- immibis 3y ago
  That's a highly unusual attitude for systemd. Most of the systemd architecture requires you to run systemd for everything if you use it at all. What changed?
  - poettering 3y ago
    Nothing changed. You are just a victim of FUD on the Internet, my friend. That's all.
    - immibis 3y ago
      Why does this remind me of something a Bitcoin or Gamestop fanatic would say?
- generalizations 3y ago
  Oh cool. Does that mean the TPM key is set up to use one of the LUKS key slots?

poettering 3y ago

To my knowledge Ubuntu does not use the TPM2 PCR logic systemd provides at all, but their own.

egberts1 3y ago

Shifting PIN to an XDM? Does anyone remember the good ol' days of hitting spaces 127 times at a SunOS "login:" prompt to gain its root shell?