does full disk encryption really need LVM?
 

i want to do full disk encryption on a disk. here are some details:

1. the disk is /dev/sdc, not /dev/sda.
2. its passphrase will be entered manually.
3. i will be mounting it via the admin user (auto-logged-in, sudo authorized)
4. home directories for most users will be on it (not root or admin).
5. i may, some day, have container and/or virtual machine systems in some form on it.
6. there may be only one partition or there may be more than one.
7. it is intended to secure even the partition table and boot sector.
8. i may want to do other disks and memory sticks this way.
9. i want to use the simplest mechanism for encryption, even if it involves more work.

do i really need to use LVM, as every instruction page i have found online would have me do? to me, LVM is adding more work for the system to do. i am not counting the crypto that is being done as part of that work.

does anyone know of a non-LVM way to deploy full disk encryption that i will not be booting from? i am using Xubuntu 18.04.6 and later on 22.04 LTS (freshly installed onto a non-encrypted disk then upgraded as needed). there is no dual-booting on this system

There are MANY disk/partition/volume encryption tools for Linux. You should look up several, examine their advantages and disadvantages, and select one that fits your risk evaluation, security needs, and work profile.
Some places to start https://www.ubuntupit.com/best-disk-...are-for-linux/ or perhaps https://www.tecmint.com/file-and-dis...ols-for-linux/ and possibly something from https://linuxsecurity.com/features/b...ools-for-linux.

It's your foot, and your gun.

The entire exercise should at least be educational. A LUKS (e.g) container is just a block device once its opened; feel free to construct a partition table therein. T'were it me, I would encrypt the entire device (without partitioning).
Good luck with your plans for /home.

tl;dr - use LVM, it has all the plumbing already tested.

I dunno what you mean, but personally I only ever used LUKS in recent times.

I partition my disks "normally" and manually create with cryptsetup etc or through some tools do it automatically (like distro installer). I've used this for partitions and full disks internal and external. Never had a problem.

right! but should i go with revolver or semi-auto?

the plan is to do full disk encryption to make a new full disk device appear. then partition that new device. I/O to all sectors would go through encryption or decryption. if the disk is stolen, the thieves would have no knowledge of how it's encrypted. i would enter the passphrase after it is booted up as part of adding the disk to the running system. then file system(s) can be mounted.

If you encrypt the entire device and then partition the encrypted container, you will have to add an extra step, probably a call to kpartx, in the init scripts to scan that container for partitions.

If you use LUKS, the header on the device will proudly proclaim that this is a LUKS container and tell the encryption parameters, other than the key of course. You could hide that identification by using LUKS with a detached header stored elsewhere, or else set up the encryption without LUKS. For the latter, you will have to specify any non-default encryption parameters (cipher specification, hash method, key size, etc.) each time the container is unlocked.

This article outlines various scenarios, with - as far as I can see - full instructions.
Take your pick, make your choice.

I second that, it's an excellent article and covers pretty much any scenario or questions anyone might have.

looks like some good reading to do. thanks for the link.

for my case, it will be manually done when that encrypted device is needed. it will not be in init scripts. part of the intention is to make it look like an ordinary system booting up. it won't ask for the pass phrase until the script is run. that will happen manually. so kpartx can be in the "setupsdc" script.

As long as you will be manually invoking some script to set up the access, there is almost no limit to how and how deeply you can arrange the various levels of abstraction. Right now I'm looking atSeem strange? Not at all, when you consider that "File 1" is actually the storage volume for a virtual machine, which then "does its thing" with partitioning, LVM, encryption, etc. I don't normally try to access anything below the level of "File 1" from the host, but I certainly could (given that I know the encryption key, of course).

And, if that virtual machine were hosting VMs of its own, then the nesting would continue on, deeper and deeper.

so it understands the filesystem used to distinguish File 1 and File 2? does it go through the kernel to do that? can that filesystem be concurrently mounted by the system level that has access to that image with the filesystem? can it use any filesystem type the kernel supports? can it do a collective RAID (randomly scattered pieces joined into one contiguous image)?

i'd prefer every byte on the entire drive look like total gibberish. maybe it would be better to have locations with actual filesystems be encrypted with a different key since those ready to crack the drive could be thinking "we know what LVM bytes look like. clue #1 to cracking her key."

File 1 and File 2 are on two separate filesystems. I'm not sure what you mean by "concurrently mounted," but no, the VM that uses File 1 as its virtual disk cannot be running if I want to mount that second filesystem from the host. This is just an example of how the layers can be nested. I'm not suggesting it as a solution to your problem.

At boot time, the physical drive is scanned for its partitions, the LVM logical volume is found, and the filesystem is mounted. Those first 4 levels all occur automtically -- it's normal boot behavior. If I want to look inside File 1 to find File 2, here's what I would do on the host:

/dev/sdc will not be listed in /etc/fstab to be mounted. it is not to be mounted at boot time. a hidden script will mount it with an obscure prompt for the encryption passphrase. so what happens at boot time does not matter much. it will just boot up a simple Xubuntu.

That's fine. You can arrange the layers any way you wish.