Ping a Specific Port

Question

Geeb

Asked: 2011-09-16 16:21:52 +0800 CST2011-09-16 16:21:52 +0800 CST 2011-09-16 16:21:52 +0800 CST

How to create a randomly keyed, encrypted swap partition, referring to it "by-uuid", on Debian?

772

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

7 Answers

Voted

Jun_in_Jeju · Answer 1 · 2013-01-25T04:38:13+08:00

Jun_in_Jeju

2013-01-25T04:38:13+08:002013-01-25T04:38:13+08:00

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

8

Andrew Schulman · Answer 2 · 2011-11-05T06:37:09+08:00

Andrew Schulman

2011-11-05T06:37:09+08:002011-11-05T06:37:09+08:00

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.

3

John Greene · Answer 3 · 2020-08-26T09:19:39+08:00

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.)

idupree · Answer 4 · 2011-10-01T21:59:07+08:00

idupree

2011-10-01T21:59:07+08:002011-10-01T21:59:07+08:00

Try implementing the rest of the solution, ignoring the init file. It looks like that bit of init script is only there to protect you. Either Debian doesn't protect you in that way, or it will give you an error message when you try to boot with it that will hopefully lead you to the right place.

I'd also be careful that IIRC Debian and ArchLinux have different formats for /etc/crypttab (crazy, I know, but I moved from Ubuntu to Arch a couple years ago and eventually decided to use straight bash rather than meddle with crypttabs).

0

Timothy Butterworth · Answer 5 · 2015-05-02T11:49:02+08:00

run ecryptfs-setup-swap or manually:

This Configuration uses randomly generated keys at boot and will not support Hibernation to hard disk! You Should Disable Hibernation through your respectie DE Power Management Utility and set it to Shutdown on Critical to avoid Data Loss!

Switch to an admin/root account

su root or sudo for each command

Disable Swap

swapoff -a

Locate the existing Swap Partition

lsblk

example: sda3 8:3 0 8G 0 part [SWAP]

Overwrite Old Swap

dd if=/dev/zero bs=1024000 of=/dev/sda<#>

example: dd if=/dev/zero bs=1024000 of=/dev/sda3

FSTAB setup

vim /etc/fstab

Replace old SWAP device with crypttab mapper name: /dev/mapper/cswap

OLD UUID=d03f3d8e-7888-48a5-b3cc-41de8dbbcfdc swap swap defaults 0 0

NEW

/dev/mapper/cswap none swap pri=1,defaults 0 0

Crypto Setup

ls -lF /dev/disk/by-id

Example: ata-HGST_HTS545050A7E680_TEK55D4F0BU3GV-part3 -> ../../sda3

vim /etc/crypttab

cswap /dev/disk/by-id/ata-HGST_HTS545050A7E680_TEK55D4F0BU3GV-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256

Active Encrypted Swap

Reboot The Computer

Verify Enctypted Swap Operations

dmsetup -C info

Example: cswap 253 0 L--w 2 1 0 CRYPT-PLAIN-cswap

lsblk

Example ├─sda3 8:3 0 8G 0 part
│ └─cswap 253:0 0 8G 0 crypt [SWAP]

cat /proc/swaps

example: Filename Type Size Used Priority /dev/dm-0 partition 8385532 0 -1

Brian Minton · Answer 6 · 2021-11-04T11:56:36+08:00

Brian Minton

2021-11-04T11:56:36+08:002021-11-04T11:56:36+08:00

If you're using GPT partition tables, then for instance /dev/disk/by-partuuid/d1a59352-aa44-4748-85fc-4cf785702f99 is a stable device name that's not going to change even when the contents change.

0

David Tonhofer · Answer 7 · 2022-06-23T06:44:22+08:00

Not Debian but Fedora 36

Confirming that @Brian Minton's idea of using the Partition UUID held in the GUID Partition Table can be effectively used to solve this particular problem. Of course, you need a disk structure that uses GUID Partition Table, not the old-school MS-DOS partition table

For example, I want to have the volatile but encrypted swap partition on /dev/sda3 and we can find the GUID Partition UUID by looking at /dev/disk/by-partuuid/ (or by calling blkid /dev/sda3)

# ls -l /dev/disk/by-partuuid/
total 0
lrwxrwxrwx. 1 root root 10 Jun 22 09:54 1bcc8619-ab8d-4709-b1a6-dcb6ac8bdd1b -> ../../sda3

And then we just need to add appropriate lines to /etc/cryptsetup and /etc/fstab as shown (in orange) in the diagram below.

After boot, we find the following in the systemd log with journalctl:

systemd-makefs[693]: Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
systemd-makefs[693]: LABEL=cryptoswap, UUID=5d930dd4-4799-4f7a-928e-b2da1c5b9508
systemd-makefs[691]: /dev/mapper/cryptoswap successfully formatted as swap (label "cryptoswap", uuid 5d930dd4-4799-4f7a-928e-b2da1c5b9508)
systemd[1]: Finished [email protected] - Cryptography Setup for cryptoswap.
systemd[1]: Reached target [email protected] - Block Device Preparation for /dev/mapper/cryptoswap.