5

Once I already have a running Linux system installed with live unencrypted data on my HDD. Is there any reasonable way to dm-crypt that entire HDD right in place? (Without backing up then restoring or transferring to a new FS.)

If so is there any way to do it online? I.e. be able to operate my Linux system in the hour or so that it takes to encrypt all the data?

Joe C
  • 243
  • 2
  • 12
  • Not really. [There's a way](https://help.ubuntu.com/community/EncryptedFilesystemHowto7), but it's not online, and it's so error-prone that you'd probably end up restoring from backup anyway. – Gilles 'SO- stop being evil' Apr 02 '13 at 23:39

3 Answers3

7

If you (a) have enough free disk space and (b) are using LVM, you could:

  1. Take a backup.
  2. Re-read step 1, not ignoring it this time.
  3. Re-read step 1, keeping in mind I haven't actually tested this. It should work, though!
  4. Shrink your current physical volume (pvresize)
  5. Resize the underlying partition. Unfortunately, in order to re-read the partition table, you'll probably have to reboot (it's in use).
  6. Create a new partition, set up dm-crypt on it. Put a physical volume on top of that.
  7. You can now use pvmove to actually move the data, on-line.
  8. While the move is in progress, make sure to update your initramfs to boot encrypted volumes. Especially if you're encrypting everything.
  9. Have a recovery disk (e.g., live cd) ready. Reboot, make sure it comes up
  10. Remove the old pv from the volume group, and do a secure overwrite on it.
  11. You can now set up dm-crypt on that too, and add it as a second pv to the same vg.

If you're not using LVM, its probably hopeless. You could certainly use e.g., rsync to copy the data from one filesystem to another, but you'll need to do the final sync with the machine idle (otherwise, you'll have files changing as you try to copy them).

derobert
  • 107,579
  • 20
  • 231
  • 279
  • 1
    I wouldn't dare do this without taking a back-up. If the data was really being moved (not copied) then wouldn't the OS's own files be pulled out from under it? Wouldn't that make it crash? Wouldn't you need to have booted off an alternate OS, e.g. Linux on a USB key or DVD? – Joe C Apr 03 '13 at 17:37
  • 3
    @JoeC LVM runs at a low enough level that it can move the OS's files without causing an issue. LVM is beneath the filesystem; and it abstracts away the fact that its actually moving the data. Similar to how you can lose and replace a disk in a live RAID array without anything above the RAID layer noticing (except for performance, of course). – derobert Apr 04 '13 at 16:07
6

LUKS in-place encryption exists. But you need to set up your environment a little as per the pictures:

enter image description here

enter image description here

enter image description here

Frederick Nord
  • 265
  • 3
  • 5
  • 1
    It sounds like OP wants to encrypt the current primary volume in-place, in which case this - nor any other method I can imagine - will not work. Step 1 of the page you linked: "1. Unmounting the filesystem" – underscore_d Sep 24 '15 at 18:35
  • Right. We're not there yet. But the requirement "Without backing up then restoring or transferring to a new FS" appears to be satisfied. Also, modern filesystems can be resized while mounted. It might be possible to use luksipc with those. – Frederick Nord Sep 25 '15 at 16:15
2

Tools are supposed to exist but I cannot offer a name or URL. But if you are not afraid :-) then it's not even difficult. All you have to do is read from the unencrypted device and write to the encrypted device. And you cannot use LUKS unless you resize the filesystem before to make it a bit smaller. And of course this does not work with the device being mounted (probably not even if it's mounted ro). The core function (without any protection against crashes) is this (and yeah, I just tried it successfully):

for((i=0;i<100;i++)); do
  echo "Copying block with offset ${i} to tmpfs"
  dd if=/dev/storage2/test of=/mnt/tmpfs/cryptoblock skip=$i bs=10M count=1 &>/dev/null
  echo "Copying block with offset ${i} from tmpfs"
  dd if=/mnt/tmpfs/cryptoblock of=/dev/mapper/crypt_test seek=$i bs=10M count=1
done

The obvious demand for improvment is: copy the blocks to a non-volatile medium instead and log their offset. In case of a crash you manually copy the block of the interrupted transaction and start the loop with the offset of the next block as start value.

Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
  • 1
    You would have to have booted off another OS to do this, right? What would be the first step? You can place a dm-crypt mapper on top of a partition with live data, then access right around it and get the raw data without attempting to decrypt it? – Joe C Apr 03 '13 at 17:45
  • @JoeC Not necessarily. You have to boot a different OS (installation) only if the device to be encrypted is necessary for booting the usual one (like the root FS). But if that partition just stores data (or is /home) then you are free to unmount it and do whatever you like. What is "live data", a device mounted read-write? You can read the data from the device without decryption until it gets derypted. You read an unencrypted block and have dm-crypt encrypt it and replace the old data with it. – Hauke Laging Apr 03 '13 at 20:55