- 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.
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'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)
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 + 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.
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..."
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
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.
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.
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.
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
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.
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).
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!
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.
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?
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.
> 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.
- 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.