How to create a randomly keyed, encrypted swap partition, referring to it "by-uuid", on Debian?
It is sensible that if you have any sort of block device encryption implemented on your GNU/Linux system, to encrypt your swap partition too, as any decrypted data may be written in cleartext at any time to the swap.
Looking at the debian man page for "crypttab" I see an example of creating a randomly keyed swap partition on boot-up, so the key is set randomly as the boot proceeds and known only to the system itself:
# Encrypted swap device
cswap /dev/sda6 /dev/urandom cipher=aes-cbc-essiv:sha256,hash=ripemd160,size=256,swap
In this example the swap device is referred to by a conventional dev path i.e. /dev/sda6
Absolute device paths are subject to change and be re-assigned at boot-up if, say a usb drive is plugged in, for example. A user would be very unhappy if /dev/sda6 happened to be a different partition than expected and it was subsequently overwritten with random swap data!!
So the solution would seem to be: use a UUID instead of a device path (as a UUID shouldn't change), replacing /dev/sda6 with /dev/disk/by-uuid/<whatever the uuid of dev/sda6 is>
BUT ... here's the problem: Every time cryptsetup recreates the encrypted swap partition at boot time it generates a new UUID for it! Doh!
So we need to preserve the UUID of this encrypted filesystem somehow. I think cryptsetup can do this with its --offset switch, allowing for preservation of the LUKS header and thus the UUID.
I have found this URL: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_UUIDs_with_encrypted_swap_partitions
Does anyone know how to implement the solution described for Arch Linux on the Debian OS? The init scripts referred to in the document seem not to exist on the Debian OS
Thanks!
EDIT
One could use ecryptfs to achieve the same ends (encrypted swap space) using the command:
ecryptfs-setup-swap
Without the problems that beset block device encryption.
Have a look at this AskUbuntu query
Every time cryptsetup recreates the encrypted swap partition at boot time it generates a new UUID for it! Doh!
In /etc/crypttab, use /dev/disk/by-id instead of /dev/disk/by-UUID to refer to your swap partition. For example, your /etc/fstab entry for swap might be
#<file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/cswap none swap sw 0 0
Then the correct corresponding entry in /etc/crypttab would be something like
# <name> <device> <password> <options>
cswap /dev/disk/by-id/ata-SAMSUNG_SSD_830_Series_S0XYNEAC762041-part5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256
Notice that the device above is referred to by /dev/disk/by-id which you can find out for your drive by typing the following at the CLI:
ls -lF /dev/disk/by-id
In my /etc/crypttab, I have
# <target name> <source device> <key file> <options>
swap /dev/mapper/cswap /dev/random swap
Here /dev/mapper/cswap is a logical volume created by LVM, which takes care of correctly assigning logical volume names regardless of the drive letter names. It also allows me to easily resize my swap partition.
To do a swap on encrypted file over LVM partition while using by-uuid option
is not possible ... during initramfs boot stage or during most of systemd boot stages.
Here's why...
Or skip to "Steps" section to get started for an equally safe encrypted LVM swap space that gets created during normal bootup stage (for systemd, Debian 10).
Assumptions
You created an LVM partition named lv_swap_encrypted using
100% of vg_swap VG space as followed:
lvcreate -l 1000%VG -n lv_swap_encrypted vg_swap
such that our goal is to have the following logical diagram:
/dev/sda3
LVM Physical Volume (PV)
/dev/mapper/dm-7
LVM Volume Group (VG)
/dev/vg_swap
LVM Logical Volume (LV)
/dev/vg_swap/lv_swap_encrypted
cryptsetup plain
/dev/mapper/swap_unencrypted
swap space
Problem
Take a look at the newly created LVM partition named vg_swap-lv_swap_encrypted
just for use with swap (or encrypted swap):
# ./lsblk-uuid
NAME UUID MOUNTPOINT
sda
├─sda1
├─sda2 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /boot
├─sda3 XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
│ └─vg_swap-lv_swap_encrypted
└─sda4 XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
├─arca_v1-root XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /
└─arca_v1-spare
...
Notice that there is no UUID for that vg_swap-lv_swap_encrypted partition?
You COULD execute mkswap vg_swap-lv_swap_encrypted on that LVM
and obtain that UUID but then we would be skipping the much needed
encryption part that we wanted.
WARNING: Oh, you executed mkswap? Then wipe it clean by executing:
dd if=/dev/urandom of=/dev/mapper/vg_swap-lv_swap_encrypted
Executing dmsetup info /dev/dm-7 reveals a different UUID format:
LVM-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
I already tried the UUID= option with that funky LVM value above won't work in
the 2nd field of /etc/crypttab either. Costed me a reboot here.
Note: X represent VG UUID and Y is LV UUID in LVM parlance.
Availability of Device Links
During initramfs boot stage, not many symbolic links are available for use with boot-up stage. We investigate which device paths are available for encrypted swap.
No need to do update-initramfs or any rebuilding of initfs here.
LVM Linked Device Names
In the /dev directory, LVM creates several symbolic links
for each LV (logical volume) partition that lvcreate
(or systemd-lvm2 during bootup) activates.
During initramfs boot stage, LVM activation creates the following block and symbolic files links:
/dev/dm-X/dev/mapper/vg_swap-lv_swap_encrypted/dev/vg_swap/lv_swap_encrypted
During normal kernel boot stage, OS takes care of the rest of
the following links. No need to investigate by whom or where,
as our focus is on link availability for encrypted swap partition DURING initramfs boot stage.
/dev/block/254:X/dev/254:X/dev/vg_swap-lv_swap_encrypted/dev/lv_swap_encrypted/dev/dm-name-vg_swap-lv_swap_encrypted/dev/disk/by-id/dm-uuid-LVM-XXXXXXXXXXXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYYYYYYYYYY YYYYYYYYYYYYYYY/dev/dm-uuid-LVM-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY YYYY
Twenty reboots into runlevel 2 later, I've learned that it will
never be possible (during initramfs boot stage)
to use mount by-uuid because as each time the swapper
writes unencrypted data into the first couple of blocks into the
encrypted partition, whatever UUID it had before its encrypted data wrote
over it is now long, long gone.
For normal post-bootup stage, UUID can be used in cryptsetup/cryptdisks_*.
Let's step back away from physical and extended partition UUID to take a look at LVM UUID here: LVM management pretty much ensures that each LVM partition is highly unique.
DANGER: In short, only danger to you is by reusing this same LVM parition for something else other than swap. If so, by the next reboot, that partition gets converted back to a swap space again and any newly installed data is gone (just be glad it's not the old and precious data).
SETUP
This arrangement of going by LVM VG/LV name would be impervious to data loss caused by addition, removal, and repartitioning of a hard drive, whether it's a swap or a filesystem.
In this /etc/crypttab example:
swap_unencrypted /dev/mapper/vg_swap-lv_swap_encrypted /dev/random none
swap space using memory-based randomized-key AND using VG/LV pathname, this approach will take your existing swap partition and convert it to an encryp ted swap space.
Basically, the following steps will
- disable hibernate,
- create an LVM partition for encrypted part of swap space,
- make a new entry in
/etc/crypttab - get dm-crypt/LUKS to create yet another partition, swap_unencrypted.
- modify swap entry in
/etc/fstab - Create swap space (
mkswap) - Enable swap space ('swapon`)
all to re-encrypt the swap space now and after every reboots.
Disable Hibernate
To use randomized key, you should understand that hibernate feature gets no longer supported.
You should disable hibernate as well before going on further. Hibernate makes use of swap space and randomized keys effectively makes prior hibernation quite unusable.
Note: we WANT to set the physical or extend partition to SWAP to fool the systemd initramfs generator into NOT disabling the SUSPEND/SLEEP part.
On Debian, you can execute:
systemctl mask hibernate.target hybrid-sleep.target
systemctl restart systemd-logind.service # or reboot if using Gnome/gdm3 display manager
Good news is that hardware suspend or sleep mode will still work.
Create LVM
These steps assumes that you have a physical or extended (and not a LVM) partiti on for a swap partition already.
Re-type the Swap Partition
Assume that /dev/sda is the drive name.
Assume that 3 is the partition number of /dev/sda drive that swap is located
on.
Execute fdisk and use t option to relabel the Linux swap into Linux LVM
by entering in 31 (or you can use L to list all options after that t comma
nd.
# fdisk /dev/sda
Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): t
Partition number (1-4, default 4): 3
Partition type (type L to list all types): 31
Changed type of partition 'Linux swap' to 'Linux LVM'.
Command (m for help): w
The partition table has been altered.
Syncing disks.
Create LVM Physical Volume
Create a physical volume for LVM, by executing:
pvcreate /dev/sda3
Create LVM Volume Group
Create a volume group for LVM, by executing:
vgcreate vg_swap /dev/sda3
Nice thing about a volume group is that you can expand your swap space later on with another physical hard drive.
Create LVM Logical Volume
Create a logical volume for LVM, by executing:
lvcreate -l 100%vg -n lv_swap_encrypted vg_swap
# Make the LVM create a special file under /dev/vg_swap/lv_swap_encrypted
lvchange -a y vg_swap
Now we have a /dev/dm-7 block file available.
You will find that:
/etc/mapper/vg_swap-lv_swap_encrypted/etc/vg_swap/lv_swap_encrypted
all points to the same /dev/dm-7.
I will advocate using /etc/mapper/vg_swap-lv_swap_encrypted because it
is the consistent location that most of us can expect.
Not many know to look for this custom LVM Volume Group name here
like /dev/vg_swap. Some other (like most BOFH) who create hard-to-find
/etc/mapper_other (VG name of mapper ) to make it harder to look
for.
We will not be using /dev/dm-7 because it could be
dm-19 or other, depending on your partition layout.
Now we have a pathway to a drive, a logical drive, but not yet an encrypted driv
e with random key pointing to /dev/mapper/vg_swap-lv_swap_encrypted.
Encrypted Swap Partition
Add or modify the following entry into /etc/crypttab:
swap_unencrypted /dev/mapper/vg_swap-lv_swap_encrypted /dev/urandom swap,cipher=
aes-cbc-essiv:sha256,size=256
Then activate the encryption and create yet another dm device under /dev/mapper block device:
Choose one of two commands below:
# cryptsetup open /dev/mapper/vg_swap-lv_swap_encrypted \
swap_unencrypted
or
# cryptdisks_start swap_unencrypted
[ ok ] Starting crypto disk...swap_unencrypted (running)...done.
A new symbolic link has been made, execute lsblk
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 3.7T 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 381M 0 part /boot
├─sda3 8:3 0 15.3G 0 part
│ └─vg_swap-lv_swap_encrypted 254:7 0 15.3G 0 lvm
│ └─swap_unencrypted 254:8 0 15.3G 0 crypt [SWAP]
└─sda4 8:4 0 3.6T 0 part
├─arca_v1-root 254:0 0 186.3G 0 lvm /
... 11:0 1 1024M 0 rom
You could look at the UUID for that LVM partition, but that's useless at this point.
Execute lsblk -o name,uuid,mountpoint
# ~/bin/lsblk -o name,uuid,mountpoint
NAME UUID MOUNTPOINT
sda
├─sda1
├─sda2 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /boot
├─sda3 XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
│ └─vg_swap-lv_swap_encrypted
│ └─swap_unencrypted
└─sda4 XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
├─arca_v1-root XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /
...
Newly created block device to /dev/mapper/swap_unencrypted now exists.
Details on /dev/mapper/swap_unencrypted:
# cryptsetup status swap_unencrypted
/dev/mapper/swap_unencrypted is active.
type: PLAIN
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
key location: dm-crypt
device: /dev/mapper/vg_swap-lv_swap_encrypted
sector size: 512
offset: 0 sectors
size: 31997952 sectors
mode: read/write
Create Swap Space
Create the swap space:
# mkswap /dev/mapper/swap_unencrypted
Setting up swapspace version 1, size = 15.3 GiB (16382947328 bytes)
no label, UUID=8cd89984-9892-4d62-a9ba-ecfb6476379c
Now notice the UUID created for swap_unencrypted? This will always
be different for each reboot.
# ~/bin/lsblk-uuid
NAME UUID MOUNTPOINT
sda
├─sda1
├─sda2 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /boot
├─sda3 XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
│ └─vg_swap-lv_swap_encrypted
│ └─swap_unencrypted 8cd89984-9892-4d62-a9ba-ecfb6476379c [SWAP]
└─sda4 XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
├─arca_v1-root XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /
...
Activate Swap Space
In /etc/fstab, modify or add the line of the swap entry:
/etc/mapper/swap_unencrypted none swap sw 0 0
Then execute:
# swapon /dev/mapper/swap_unencrypted
Swap space is now being encrypted using a random key.
Since dm-crypt is using UUID provided by LVM LV block device, this
should be a sufficient answer to a functionally secured encrypted
swap space.
Conclusion
UUID cannot be used for encrypted swap partition due to schotastic nature of encrypted data that prevents identification of such partition (swap, ext4, btfs).
UUID cannot be used for unencrypted swap partition provided by cryptsetup because our goal is to refresh the swap space at each reboot.
You could use /dev/disk/by-id.
But LVM offers more than enough sufficient protection by the virtue of YOUR unique naming convention of each the VG and LV partitions.
Above setup provides an uniquely encrypted swap space locator which will be scrambled yet unrecoverable after each reboot (or in event of rare case, LVM remount.)