[Solved] Full-disk encryption with more control

[gusbrs]

I might well be asking a duplicate here, since a search for the obvious key terms in the forum returns numerous hits. So much so it is hard filter them, so I'll ask, and welcome pointers to existing threads here or elsewhere.

I'd like to fully encrypt my computer, especially my laptop. As far as I can tell, the Mint installer offers an option for full-disk encryption, but only when one chooses to "Erase disk and install Linux Mint". It also does not let one choose how the setup is done. It sets up a boot partition, a ESP partition (in my case), a "BIOS boot" partition, and the rest of the disk it sets up a Luks partition, on top of which it sets up LVM volumes, one for swap, and the rest is taken by the system, which is installed in an ext4 filesystem.

The overall structure looks good. However, I'd like to do things differently. In particular, I like to separate my user files from the system in different partitions/volumes, for it makes management easier. Also, in so doing, I'd like to have the ability to install the system without touching my personal files partition/volume. Finally, I also would like to try Btrfs for the system partition/volume.

As mentioned, as far as I can tell, the Mint installer does not offer this. But, is it even possible to install Mint if I choose to configure these things? If so, are there any up to date guides/tutorials around?

I made a quick test on a VM, installed it with full-disk encryption. Then I reinstalled Mint using the same structure the defaults offer. So I left the partitions and LVM volumes in place, but unlocked the Luks partition before launching the installer. Then I've chosen the corresponding /dev/mapper/... device to install the system, and requested it be formatted with Btrfs. The installation went through, but it booted to grub recovery, which in hindsight is to be expected. But is it even "supported" by Mint to do something of the sort and then configure some things manually?

[spamhog]

NOT NECESSARILY A SOLUTION BUT... I selectively gave up on deliberately setting up a separate encrypted data partition on laptops because of such complicatons. It's economics: the cost of synching data in and out of a single encrypted root + data partition, and of redoing an install or reimaging or restoring the OS are low enough to make single-partition a reasonable choice even if data might break the OS or viceversa.

More in your direction:

1) De facto, I ended up having something quite similar to what you try to accomplish. My notebook also contains s secondary consumer SSD, a replacement of one that failed at 80 hours. On it I imaged an older, smaller SSD, with its own encrypted root+data partition. Added that partition to /etc/fstab as noauto,users, and it is now user mountable with the same permissions. (On old and new system I am the nr. 1 user with the same username, so no friction). I didn't have to mess with the mapper. The extra partition shows up as mountable on my file manager (in my case thunar).

2) I use ~ exclusively for dotfiles and dotfolders, it looks empty, all user data incl. the mailbase and the desktop are in other folders. On one comp they are on a different spindle. Maybe you could leave the desktop in the root partition.

3) Did you try to just leave a block device unused (predefined as partition at install, and left unmounted, unformatted or formatted to anything as a placeholder/test) and encrypt it later? The ones I mentioned above are on LVM, but that's an additional level of complexity. I hear legends about resizing encrypted virtual volumes but never got down to that level of detail. Here, all of encryption and formatting-inside-encryption seem to be done inside a system running on whatever HD. Messing with partitioning a running system may be a bad idea, but messing with any one predefined partition on any HD doesn't seem too dangerous.
https://www.ibm.com/docs/en/order-manag ... using-luks

4) This is one backup disk I have. Partition 4 is an unused swap space. What follows is from gdisk:

user@host:~$ sudo gdisk /dev/sdc
[sudo] password for user:
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdc: 1953525168 sectors, 931.5 GiB
Model: WDC WD10JPCX-24U
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 7D6F2634-0AA0-4032-9D88-B530FAB44D45
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5485 sectors (2.7 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 22527 10.0 MiB EF02 bios-boot-part
2 22528 6146047 2.9 GiB 8300 HDRESCUE
3 6146048 1024002047 485.4 GiB 8300 MAXY
4 1024002048 1107658751 39.9 GiB 8200
5 1107658752 1953521663 403.3 GiB 8300 EXTRA

Command (? for help): i
Partition number (1-5): 4
Partition GUID code: 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F (Linux swap)
Partition unique GUID: 3AC53301-26F1-48BF-A33A-70AF022942A8
First sector: 1024002048 (at 488.3 GiB)
Last sector: 1107658751 (at 528.2 GiB)
Partition size: 83656704 sectors (39.9 GiB)
Attribute flags: 0000000000000000
Partition name: ''

Command (? for help): t
Partition number (1-5): 4
Current type is 8200 (Linux swap)
Hex code or GUID (L to show codes, Enter = 8200): l
Type search string, or <Enter> to show all codes: LUKS
8309 Linux LUKS f813 Ceph dm-crypt LUKS journal
f814 Ceph dm-crypt LUKS block f815 Ceph dm-crypt LUKS block DB
f816 Ceph dm-crypt LUKS block write-ahe f817 Ceph dm-crypt LUKS OSD

Hex code or GUID (L to show codes, Enter = 8200):

Setting the code to 8309 and writing seems like a good step before the IBM instructions.

Not sure I'd do it if that were the hot system disk, better from anotther OS and drive, but I'd risk it in a pinch..

[gusbrs]

spamhog, thank you very much for your suggestions.

Regarding the "economics" of having more control vs letting the Mint installer handle if for me and syncing the files later, that's currently what I'm trying to figure out, and the reason for this question. I'd like to try, and see what my "balance" is. True, there are a number of concepts/features which will require some learning on my part. I'm new to LVM, and not really acquainted with manually setting up GRUB, for example. But I'm willing to learn about those things. I may decide later it is not worth it, but I have to try someday to know.

Regarding other possible setups and your usage examples, they are welcome. My real case scenarios here include a laptop, with a single HDD, and a desktop, with an SSD plus an HDD. The desktop would thus be liable for an "easy way out", of letting the installer handle things on the SSD, and leave the HDD with my personal files. But, even that is not really what I'd like to do. For example, I wouldn't be able to handle the filesystem of the root partition. Besides, on the laptop I wouldn't have the benefit of the physical division of the media to be able to do something of the sort.

Up until now, I've been running on two partitions (plus swap and ESP), one for the system, unencrypted, and a Luks one for my personal files. That with some care of encrypting swap, using tmpfs for /tmp, and things of the sort. But I'm somewhat unsatisfied with it, truth is, whatever care you may take, things leak. So, full-disk encryption seems attractive. More complex setup up front, but simpler (and safer) after this initial cost is paid.

So, again, I want to try, or at least investigate the possibility of doing so. Thus the question, is it possible to bend the Mint installer to one such setup? Is it supported? If so, any known good sources around?

Did you try to just leave a block device unused (predefined as partition at install, and left unmounted, unformatted or formatted to anything as a placeholder/test) and encrypt it later?

No, I did not. And I don't really know if that would be possible using the "Erase disk and install Linux Mint" option. Is it?

This is one backup disk I have. Partition 4 is an unused swap space. What follows is from gdisk:

But is this the disk from where you boot and store your OS (Mint that is)? Did you setup this disc with the Mint installer?

[linux-rox]

One of my "just curious" hobbies is trying to figure out how FDE works. Just curious, as I'm perfectly content with data file encryption (and that for only a modest fraction of my files). With this broad caveat, I think the simplest path to what you want is (i) Something Else method with physical volume for encryption option (example) plus (ii) automount of encrypted data partition using keyfile (article). And I will say, I don't understand why people worry about encrypting swap unless they use hibernation. Which is to say, without hibernation, ISTM a standard swap file should be fine.

If you want to take a shot at setting up everything manually, take a look at this tutorial. Never tested, but from my research looks still valid.

By the way, I have no idea how btrfs effects any of this. Not something which interests me in general, so have made no attempt to track it vis-a-vis FDE.

[zcot]

I'll mention this tutorial, the user has been doing these advanced encryption tutorials for years. Just dig into the preface and choose the specific setup for how it applies to your setup(with or without tpm, legacy or gpt disk, uefi, secure boot, or what, etc) : viewtopic.php?f=42&t=198077

The reason I mention it is because it gives every dirty detail. If you want to do something complex and specific, then the info is in there. And the real fact is that if you are not encrypting the bootloader(any of the typical ubuntu/mint defaults are not doing that) then you are missing part of the real point of doing this in the first place, because middle man, you can get to the info from a hijacked bootloader, although sure the punk who stole your laptop from starbucks wont be doing that anyway.

[gusbrs]

linux-rox and zcot, excellent pointers. Thank you very much! They look promising and I'll work on them today.

[rene]

And I will say, I don't understand why people worry about encrypting swap unless they use hibernation. Which is to say, without hibernation, ISTM a standard swap file should be fine.

Encrypted swap makes conceptual sense. I.e., blocks in swap space aren't cleared on swap-in. So let's say you have some sensitive document open in LibreOffice, i.e., have that sensitive document sitting around unencrypted in LibreOffice's address space somewhere, and memory-pressure causes those pages of memory to be swapped out. Your sensitive document is now available unencrypted from swap-space and unless something else getting swapped out later just happens to overwrite it again, will still be even after shutting down the system [edit: and, note, even if we arrange for swap clearing we still have an issue if say our power supply dies while sensitive data is swapped out].

Something that knowingly deals with sensitive data such as encryption keys will/should mlock(), i.e., not allow the memory to be swapped out in the first place, but as in that LibreOffice example, not everything would even be aware that it's handling something sensitive. As such, and although I'm very flexible on the subject of practical sense, encrypted swap makes a lot of theoretical sense if encryption of your data by itself makes such.

[spamhog]

> And I don't really know if that would be possible using the "Erase disk and install Linux Mint" option. Is it?

It should be possible to replicate that also in manual partitioning during the install.

I tried it in a VM and it failed to mount / but I think it could be made to work. All the steps seem there.

Partitioner will show you the disk as it is, and you can put in the needed partitions and extra ones too.

You can delete the existing partitions, or you may use the existing partitions in a prepartitioned disk and optionally reformat each.

For a UEFI + crypto you need a UEFI partition (100MB is plenty), an unencrypted boot partition where the kernels and other guts will live (I reckon 1GB per kernel, actual space is a few 100MB each), the encrypted root partition with /home (I know consider a few 100GB sufficient, much of it will go to Timeshift backups), the rest is up to you.

For /, make it as "physical volume for encryption", enter passphrase, wait, it will leave an "unknown" hole in the partition list and will be listed ON TOP via the mapper, where you will see an unchangeable and a changeable entry.
Leave the hole alone in the main partition list, change the mapped encrypted partition up on top to formatting and mountpoint. No LVM needed.


As an example, I added an encrypted partition mounted on /DATA-encrypted , and an unencrypted partition mounted on /DATA-unencrypted.

I was asked for a passphrase only for the root partition, which also opens the other one.

The end result on the GUI partitioner is this (multiple shots, can't be maximized).





The partitioner asked me to raise / to 8.5G, which I refused, then warned:


At this point I got an error as the partitioner couldn't mount the / partition, but atm I think in principle the whole thing should work.

[t42]

.. (i) Something Else method with physical volume for encryption option (example) plus (ii) automount of encrypted data partition using keyfile (article).
---
If you want to take a shot at setting up everything manually, take a look at this tutorial.

The linked articles are useful, but I noticed as these and many others tutorials and instructions are skipping the step of filling the device with random data, blurring the boundary between ciphertext and noise. Please note that it is sine qua non in case of VeraCrypt hidden volumes, which is needed to provide plausible deniability (of course, VeraCrypt is taking care of this for you).
As for the deniability, people who are require the encryption of their data not for educational purposes, need to think over their strategy explaining to the adversary presence of high-entropy data on their storage - it's probably a futile attempt if the adversary is competent enough.

[t42]

...
... encrypted swap makes a lot of theoretical sense if encryption of your data by itself makes such.

Indeed swap configuration is really important. As Milan Broz said, to prevent sensitive things to end up in swap, one solution is to encrypt swap at a boot time, another is

to run without swap, which generally works well in a desktop-context

Anyway I think the second option can't be recommended. If you don't have a swap partition, when your system is sleeping, the decryption keys will be stored in RAM as plaintext.
In case of swap file instead of swap partition, please note that without hibernation you will be suspended to RAM with the same effect, with LUKS keys stored in RAM unencrypted.
Another point, sometimes there are recommendations to re-encrypt swap on each boot with a key seeded by urandom. This will take no effect, ( these options are ignored for LUKS devices, according to the crypttab manual man 5 crypttab
This is wrong: swap UUID=xxx /dev/urandom cipher=aes-xts-plain64:sha512

[gusbrs]

rene, spamhog, t42, thank you for your comments and suggestions.

spamhog, indeed, the interesting question is how to get things working with manual partitioning. And the tutorials suggested by linux-rox and zcot show not only that it is possible, but also how to do it. They are a lot to sink in, since going that route means that a number of informed decisions must be made. I did fancy a setup with: EFI with GPT partition table, with an unencrypted /boot, and everything else on a Luks partition, LVM on top of Luks, separated volumes for root and my personal files, and root formatted with btrfs. I could get this working today with the help of the suggested tutorials, in particular following closely (with due adjustments) the one recommended by linux-nox, namely: viewtopic.php?t=228836. But all pointers were very useful to get a grasp of the main issues to handle and options available.

Thank you all.

[spamhog]

I tend to delay dealing with swap, current default is a small file that can fall inside an encrypted partition.

If deniability isn't an issue, you can also later fill the encrypted partition with a random file with eg sudo dd to sweep over the root quota, and delete it automatically as soon as dd exits for lack of space. I have a risky script somewhere that mounts all partitions, runs sudo bleachbit blind -yes to all, zeroes all partitions with files, deletes them as soon as full, plays some music and powers off.