Ask HN: What Do You Use for Linux Full Disk Crypto?
50 コメント
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.
- 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.
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.
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.
During installation, I tick the box that says 'full disk encryption'.
this. it was the easiest thing ever.
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.
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.
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.
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.
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).
Bonus points if it's possible to install to a partition in existing FDE container (saves a /home backup-restore external drive round trip).
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.
> 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.
OP may have stated LUKS, but the Ubuntu installer doesn't.
https://i.stack.imgur.com/6Heoq.png
https://i.stack.imgur.com/6Heoq.png
[deleted]
>what do you use
luks
>what do you use to manage
cryptsetup
>prefer a more enterprise solution...
You have exotic needs, I doubt there is any open source solution that fits, you have to write your own.
You can start by reading this arch page: https://wiki.archlinux.org/index.php/dm-crypt/System_configu...
luks
>what do you use to manage
cryptsetup
>prefer a more enterprise solution...
You have exotic needs, I doubt there is any open source solution that fits, you have to write your own.
You can start by reading this arch page: https://wiki.archlinux.org/index.php/dm-crypt/System_configu...
(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
The PR started 3 years ago: https://github.com/zfsonlinux/zfs/pull/4329
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)
It's a shame it cripples the performance though. It roughly quartered sequential read/write for me.
Can you explain to me why i should use zfs instead of ext4?
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.
LUKS with TPM2-backed key: https://github.com/electrickite/luks-tpm2
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.
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.
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.
LUKS can use a central recovery key.
Regular users can't mess with LUKS settings.
Regular users can't mess with LUKS settings.
+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.
> 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.
I have a yubikey, and this[0] tutorial has been open in a browser tab for I swear four months or more. I just haven't summoned the guts to do it -- a voice in my head keeps whispering "you'll brick your laptop, you'll brick your laptop..."
[0] https://github.com/agherzan/yubikey-full-disk-encryption
[0] https://github.com/agherzan/yubikey-full-disk-encryption
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
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
This article gives a good overview of the options and potential threats: https://www.whonix.org/wiki/Full_Disk_Encryption_and_Encrypt...
Use whonix itself and read the privacy guides in its wiki if you are concerned with privacy beyond FDE.
Use whonix itself and read the privacy guides in its wiki if you are concerned with privacy beyond FDE.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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
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
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.
A user who wants to destroy data can do so regardless. Storing a key centrally only guards against accidental loss of the key.
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.
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.
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.
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.
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).
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).
The parent was referring to doing it after the installation and he is right, it can't be done without serious hassle.
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!
So, then, after installation, yes, I could see how that would be a nightmare. I have never attempted it!
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.
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.
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.
I did it "manually" a while ago: https://glandium.org/blog/?p=139 https://glandium.org/blog/?p=141
There are more automated ways to do the conversion now. Here's the first one I found while searching for my own blog posts above: https://www.johannes-bauer.com/linux/luksipc/
There are more automated ways to do the conversion now. Here's the first one I found while searching for my own blog posts above: https://www.johannes-bauer.com/linux/luksipc/
> 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".
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".
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_...
Edited to add: The best I could find was this discussion: https://www.reddit.com/r/sysadmin/comments/5fllep/whats_the_...
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.
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.
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?
> 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.
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.
Usually just Veracrypt since I can use it on Windows as well..
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.