HN Explorer

Ask HN: What Do You Use for Linux Full Disk Crypto?

44 points by otterwww ↗ HN
What do you use to manage Linux full disk encryption centrally (like BitLocker and FileVault let you do)?

I know you can do FDE with LUKS but would prefer a more enterprise solution where I can store a recovery key centrally that a user can’t remove.

50 comments

[ 2.4 ms ] story [ 77.9 ms ] thread
rwmj
LUKS + Clevis and Tang does all that you want. http://www.admin-magazine.com/Archive/2018/43/Automatic-data... There's no way to prevent a determined user with root access from removing a key, except maybe some kind of locked down trusted boot scenario which will undoubtedly create more problems than it solves.
8fingerlouie
FDE doesn't protect in case someone breaks in.

Its purpose is to protect data at rest, and if you keep it available in its unencrypted form, you're not gaining anything from it.

Daniel_sk
I wish it was so easy as on MacOS or Windows - where you can essentially turn it on with one button. I don't think enabling encryption on an existing installation of Linux can be done without reinstalling or a lot of work.
throwaway77384
Ackchually, enabling full disk encryption via LUKS is rather easy on Manjaro. It's literally a button that states "use full disk encryption" as part of the setup wizard. You then enter a password and that's it.

The tricky bit is if GRUB breaks (hint: GRUB looks for every opportunity to break. If it can break, it will) and you have to chroot into an encrypted LUKS partition. That's where your average user will be SOL. Not sure how the recovery process would work for Bitlocker or FileVault.

Nux
The parent was referring to doing it after the installation and he is right, it can't be done without serious hassle.
majewsky
I can see why that's useful for Windows or MacOS, where most users get the OS preinstalled when purchasing the machine. But Linux is installed by the user themselves (or a trusted person) 99% of the time, so it's usually sufficient to set it up at install time.
chopin
For me, not so much. I installed Mint and skipped the step (as to not to introduce more complexity the first time), thinking 'I can do that later'. The disk is still unencrypted... Is there a way to do this and to restore the system state (installed software etc.)? DuckDuckGo didn't reveal anything conclusive.

Could anybody comment on the convenience of Linux encryptions (eg. LUKS)? In Windows, encryption is totally transparent to users (I need only to type the account password). I wouldn't mind typing in two passwords, other users on the systems not so much.

r3bl
You can encrypt /home/<user> relatively easily, but you can't avoid having to type in two passwords if you want FDE.

You have to decrypt the hard drive to reach the login screen, and other users would have to do the same as well. You don't need to share any of those two passwords, since LUKS has up to 8 password slots I believe.

saint_abroad
> In Windows, encryption is totally transparent to users (I need only to type the account password).

With transparent encryption, Windows decrypts the disk at boot using the TPM. Prior to login the disk is already mounted (decrypted).

It provides an easy way for enterprise to say, "yes- we have FDE".

chopin
So there is no protection if the entire device is stolen (or put in a backroom at a border)? You can just boot it up and acess the disk without having a user? The Wikipedia page on Bitlocker does not mention this problem for TPM mode. Or is only a part decrypted until a user logs in?

Edited to add: The best I could find was this discussion: https://www.reddit.com/r/sysadmin/comments/5fllep/whats_the_...

throwaway77384
Ah, having re-read the post, I still don't really get that from it, but that's probably just down to me missing the point regarding central management of keys.

So, then, after installation, yes, I could see how that would be a nightmare. I have never attempted it!

Leace
For modern setups that support UEFI, GRUB is unnecessary as you can boot Linux kernel directly as EFI executable.

If one cares about SecureBoot then this package automates everything: https://github.com/andreyv/sbupdate (it's setup only once and works later without supervision).

wheelerwj
on MacOS its pretty easy... i use it, i think? and Windows its relatively simple too since they added BitLocker in 10. i think every os supports it?
r3bl
> and Windows its relatively simple too since they added BitLocker in 10.

Not really. OEM installs have it, but Windows 10 Home doesn't. If you're on an OEM install and decrypt the hard drive once, you won't be able to re-encrypt it without paying for a Pro upgrade. That mistake costs $100.

rb666
(very soon) ZFS! It's happening: https://github.com/zfsonlinux/zfs/releases

The PR started 3 years ago: https://github.com/zfsonlinux/zfs/pull/4329

qalmakka
I've been using ZoL-git with Datto's encryption since 2017 on my main systems. It's really really solid and makes the management of encrypted datasets a breeze (even send and receive are supported). Yes, probably is slightly less sicure than LUKS/GELI and similar block-level encryptions, but I personally do not care that much. I can't wait to see it in stable ZoL and in FreeBSD (I'm also kinda hyped for ZoF, which I hope will allow to share easily pools between Linux and FreeBSD)
Biskit1943
Can you explain to me why i should use zfs instead of ext4?
atmosx
You can compare ZFS to BTRFS, Ext4FS belongs to the late 90s. Comparing ZFS to Ext4 is like comparing a Pentium 100 Mhz to a Quad Core, asking why would someone want to use the quad core.
throwaway9d0291
It's a shame it cripples the performance though. It roughly quartered sequential read/write for me.
mrkeen
During installation, I tick the box that says 'full disk encryption'.
wheelerwj
this. it was the easiest thing ever.
ergo14
Only if you want to have a single partition :( If you want to have separate ones you have to do manual dance around luks. I'd wish it was easier to set up for multiple partitions.
dmm
Use a single partition as an lvm physical volume. Then you can have as many partitions in that as you want. This is what the Debian installer does by default if you select disk encryption.
ergo14
Its been a while since I used Debian - need to check that out. In ubuntu currently when you select FDE it partitions things on its own. If you want separate /home you need to create LVM layout by hand before you start the installer an update grub/crypt setup after install is done.
dopeboy
I just ran into this when I installed ubuntu and wanted to preserve dual boot. Definitely more room for improvement on the "Just Works" front here.
jusssi
Which distro are you using? The last I tried with Ubuntu, it "just didn't work", i.e. failed with very unhelpful error message.

Bonus points if it's possible to install to a partition in existing FDE container (saves a /home backup-restore external drive round trip).

Faaak
Works well for me on Ubuntu 18.04 and 18.10
rkangel
Works well for me in Fedora (28 and 29).
jstanley
OP specifically stated:

> I know you can do FDE with LUKS but would prefer a more enterprise solution where I can store a recovery key centrally that a user can’t remove.

majewsky
What problem are you trying to prevent?

- A novice user fatfingering `cryptsetup luksRemoveKey`? Sounds extremely unlikely.

- A determined user trying to deliberately destroy information? A lot of things are easier, e.g. `dd if=/dev/zero of=/dev/sda` to `shred important_document.pdf`.

The only thing that would protect against most accidental-destruction scenarios is not giving the users root access, and then you don't have to worry about users removing LUKS keys anyway.

jstanley
In the past I have used LUKS and simply stored a copy of the passphrase centrally. Not very "enterprise" though.

A user who wants to destroy data can do so regardless. Storing a key centrally only guards against accidental loss of the key.

8fingerlouie
I'm using LUKS, with disks being mounted with crypttab.

The keys for the drives are stored on an encrypted USB key, and the key for the encrypted USB key is stored on the root SSD.

I wanted something where i could boot unattended, and at the same time i wanted the possibility to destroy the keys and render the disks useless.

I have an encrypted backup of the keys, stored outside of the encrypted disk arrays.

xorcist
LUKS can use a central recovery key.

Regular users can't mess with LUKS settings.

saint_abroad
+1

> a more enterprise solution where I can store a recovery key centrally that a user can’t remove.

The enterprise solution is to not give users administrative privs.

jason_slack
Actually, this poses a question. I have disk encryption enabled on my laptop.

Now I want to put in a larger hard drive and clone the current drive on to it. Without disk encryption I could use clonezilla or other tools. With disk encryption enabled I can't seem to do anything to clone.

What is a solution?

ornitorrincos
Haven't done it, but as a first guess.

prepare an encrypted partition in the new disk and mount both origin and destination with cryptsetup.

now use clonezilla to clone the partitions, not the drives.

zAy0LfpBZLC8mAC
Why would it matter whether the disk is encrypted? No clue what clonezilla is or does, but dd certainly doesn't care whether a partition you are copying is encrypted.
pnutjam
I think clonezilla uses partition specific tools for copying. You could dd to a new drive, but you would not be able to enlarge the partition. You would need to create a larger partition manually an copy data.

You might be able to do a fresh install (same version) and then copy over it with your existing installation. You'd have to mount both partitions.

ef004
prepare an encrypted partition on the new drive, then mount both the new and the old encrypted partition and rsync/cp -R everything over? i guess you need to take care of the boot loader and maybe /etc/fstab separately

alternativly, clonezilla should be able to back up your partition if you cryptsetup open it but I've never used clonezilla so I don't know for sure

Tsiklon
Assuming you're using Linux, if you're using LVM on LUKS:

Back everything up first.

- Boot to a live disk.

- DD the disk from the first sector to the end of /boot over to the new disk.

- open your preferred partitioning tool to fix the GPT (as no backup GPT will be present on the second disk)

- remove the partition denoting crypto-vol1 from the second disk - note the first sector

- add a new partition starting from the original start of crypto-vol1 to the end of the disk

- FSCK the partition /boot sits on

- create a second crypto volume on the new partition on the second disk

- create a single Physical volume on Crypto-Vol2.

- add the PV to the same Volume Group as the PV containing Crypto-Vol1

- PV Move everything from Crypto-Vol1 -> Crypto-Vol2

- extend your logical volumes to the desired length with lvextend, and complete the work with your filesystem's resize tool

At this point all your data is present on the new disk

From here you'll want to mount the filesystems and chroot into the system - you'll need to edit /etc/crypttab replacing the entry for Crypto-Vol1 with the UUID for Crypto-Vol2. Then you'll need to regenerate your initramfs to load the new crypttab. This will allow you to boot from the system on the new disk.

I've likely forgotten something here - It's quite an involved process - but not impossible.

convery
Usually just Veracrypt since I can use it on Windows as well..
rca
You can probably use luksHeaderBackup and luksHeaderRestore to make sure your recovery key will always work with the volume. Although I've never tried it so don't take my word for it, it should be pretty easy for you to try out.

Not that it will prevent any dedicated user with root rights from locking you out of the data if they wish to. It just raises friction from a simple luksRemoveKey

craftoman
I'm using Debian with full disk encryption using the help of Debian Installer. Such a great tool, during installation and setup sometimes you might get confused when messing up with physical and encrypted partitions.