[SOLVED] Why installers only offer encryption for LVM?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
On all common distros (Debian, openSUSE, Ubuntu, Fedora, Mint...), at installation time you can only choose encryption if you choose to have a LVM setup. But why? Why can't you set a LUKS just on the partition you want without using a LVM setup?
On all common distros (Debian, openSUSE, Ubuntu, Fedora, Mint...), at installation time you can only choose encryption if you choose to have a LVM setup. But why? Why can't you set a LUKS just on the partition you want without using a LVM setup?
You can, the problem is now detecting what is a crypt volume and what is not while booting the system, LVM works with LUKS so well because LVM contains everything in a primary volume which then can be encrypted to make everything under it (all partitions encrypted). if you used LUKS on a raw disk how would the boot process unlock the drive? INIT or SYSTEMD have no clue what devices you have, they look at the fstab to mount... problem is adding luks to find and open every volume would be another step... if you really wanted to just rewrite the startup script so it does do it... not really a big deal. Its just not prepackaged, like a lot of things.
I just tried the Fedora 20 installer, and it let me create ordinary partitions with encryption, the only restriction being that the /boot partition cannot be encrypted.
I just tried the Fedora 20 installer, and it let me create ordinary partitions with encryption, the only restriction being that the /boot partition cannot be encrypted.
That is typically what needs to be done. The /boot partition needs to be the source of truth for how to start the system (including decryption) on a normal partition. The same applies when you're booting your system from software RAID (mdadm). The boot partition has to be on regular non-RAID disk so that it initializes the RAID and boots.
Throwing LVM in the mix does not change that requirement. I believe it is simply a design choice of the maintainers.
Actually, GRUB 2 can handle an encrypted /boot, but I don't know of any installers that set up the GRUB configuration with "GRUB_ENABLE_CRYPTODISK=y". Here is a link to one person's success story.
You can, the problem is now detecting what is a crypt volume and what is not while booting the system, LVM works with LUKS so well because LVM contains everything in a primary volume which then can be encrypted to make everything under it (all partitions encrypted). if you used LUKS on a raw disk how would the boot process unlock the drive? INIT or SYSTEMD have no clue what devices you have, they look at the fstab to mount... problem is adding luks to find and open every volume would be another step... if you really wanted to just rewrite the startup script so it does do it... not really a big deal. Its just not prepackaged, like a lot of things.
This is one of the reasons we use an initrd. For something like cryptsetup, initrd.img will be updated with the UUID of the encrypted volume. No need to check every volume.
Doesn't Ubuntu installer suggest the ecryptfs encryption, only on the /home mounted fs? ecryptfs doesn't need LVM because it's a filesystem encryption.
LUKS (that is device level encryption) neither needs strictly LVM as far as I know. I've an encrypted Slack installed on common partitions but the root partition needs to be unencrypted (maybe is the boot partition that strictly needs to be in clear?).
My schema is
/ clear
/tmp light encryption (password1)
/home more strong encryption. (password2)
I think that for my security needs (protecting data from hypothetically stolen notebook) having the root in clear does not imply a big risk. So I've not structured my disk with LVM.
only boot partition need to be unencrypted. Of course you can use LUKS on any filesystem, as it encrypts at block level. In fact, I use LUKS to encrypt stand-alone ext4 and NTFS partitions, and also a LVM.
But my question was why most distros only offered encryption if one decided to go for a LVM.However, with the latest versions this seems to be changing, as rknichols said.
Just a question - if the boot partition gets corrupted is there any way to decrypt the data?
If you use a passphrase to unlock the data, then any rescue or installation CD/DVD that supports LUKS (and LVM, if you used it) can be used to unlock and access the partition. If a key file is required, you would of course have to have a copy of that key file available. I've used SystemRescueCD to access LUKS encrypted LVM volumes. In fact, I verified that I could do that before setting up a system that way.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.