Lab 10.2 Solution

thebiz

I had problems getting the solution for Lab 10.2 to work on Ubuntu 14.04 (discussed below). I found a solution that works (http://askubuntu.com/questions/463661/encrypted-swap-partition-for-14-04).

However, somewhat annoyingly the volume /dev/sda6/ disapears from the output of sudo blkid after rebooting. Consequently, I have not been able to use a UUID to make identifying the physical device at boot more robust than /dev/sda6. This seems to be contrary to the manpage which says "...Instead of giving the source device explicitly, the UUID is supported as well, using UUID=..." (See Diagnostic Information A).

Incompatible cryptsetup command and /etc/crypttab entry in Lab 10.2 Solution?:

The cryptsetup command seems incomptible with the /etc/crypttab entry because cryptsetup prompts for a passphrase. Whereas the /etc/crypttab entry uses /dev/urandom for its key file (See Diagnostic information . If you compare the cryptsetup commands from 'Lab 10.2 Solution:'

$ sudo cryptsetup luksFormat /dev/sda11 # may use --ciper aes option

$ sudo cryptsetup luksOpen /dev/sda11 swapcrypt

and

:~$ sudo cryptsetup -d /dev/urandom create cryptswap /dev/sda6

:~$ sudo mkswap -f /dev/mapper/cryptswap -v1

(from: (http://askubuntu.com/questions/463661/encrypted-swap-partition-for-14-04))

I would suggest this is why the encrypted swap partition was not ready after reboot in the Lab 10.2 Solution.

So to summarise my questions are:

1. If the /dev/sda6 disapears from sudo blkid output after reboot how may I identify and mount the device with a more robust method such as UUID=?

2. If you are going to use the /dev/urandom method of encryption is it necessary to specify it both within the cryptsetup command and the /etc/crypttab command?

As usual I expect I have misunderstood some aspect/s so I thank you in advance for making the effort to set me straight.

Diagnostic information A:

:~$ sudo blkid # before reboot

[sudo] password for thebiz:

/dev/sda1: LABEL="Win7" UUID="FAEEAD46EEACFBCF" TYPE="ntfs"

/dev/sda2: UUID="123EABF73EABD251" TYPE="ntfs"

/dev/sda4: LABEL="LENOVO_PART" UUID="32588AD8588A9A6D" TYPE="ntfs"

/dev/sda5: LABEL="Ubuntu" UUID="0288dc9a-30c5-4a83-ace9-c8c93318a798" TYPE="ext4"

/dev/sda6: UUID="ad5d344a-f00a-4bbe-92ba-2f9d1e393799" TYPE="swap"

/dev/sda7: LABEL="CentOS" UUID="722a724d-9bdb-4e6b-b7c0-4e7a22e24380" TYPE="ext4"

/dev/sda8: UUID="8528880f-a0d6-4e5a-8f59-a445f72d8863" TYPE="swap"

/dev/sda9: LABEL="OpenSUSE" UUID="7cf9c051-88ce-4d17-905c-d39d2c58c415" UUID_SUB="3d3fdd6b-5511-41fe-ac5e-fbb6f4a2d7b1" TYPE="btrfs"

/dev/sda10: UUID="cad1d000-7ecd-453d-bb3e-c28790d85bee" TYPE="swap"

/dev/sda11: UUID="6d721972-8566-409e-b796-c1429d7670b0" TYPE="crypto_LUKS"

/dev/sdb1: LABEL="mydocuments" UUID="0AAACA9649E772A8" TYPE="ntfs"

/dev/sdb2: UUID="697d8f2a-4d77-4a4c-b48a-a90a525e31b1" TYPE="ext4"

/dev/mapper/secret-disk: UUID="a6fca341-8e25-463b-8e67-7b6a1fdc82c7" TYPE="ext4"

:~$ sudo swapoff -a

:~$ sudo cryptsetup -d /dev/urandom create cryptswap /dev/sda6

:~$ sudo mkswap -f /dev/mapper/cryptswap -v1

:~$ sudo reboot

:~$ sudo blkid # after reboot

[sudo] password for thebiz:

/dev/sda1: LABEL="Win7" UUID="FAEEAD46EEACFBCF" TYPE="ntfs"

/dev/sda2: UUID="123EABF73EABD251" TYPE="ntfs"

/dev/sda4: LABEL="LENOVO_PART" UUID="32588AD8588A9A6D" TYPE="ntfs"

/dev/sda5: LABEL="Ubuntu" UUID="0288dc9a-30c5-4a83-ace9-c8c93318a798" TYPE="ext4"

/dev/sda7: LABEL="CentOS" UUID="722a724d-9bdb-4e6b-b7c0-4e7a22e24380" TYPE="ext4"

/dev/sda8: UUID="8528880f-a0d6-4e5a-8f59-a445f72d8863" TYPE="swap"

/dev/sda9: LABEL="OpenSUSE" UUID="7cf9c051-88ce-4d17-905c-d39d2c58c415" UUID_SUB="3d3fdd6b-5511-41fe-ac5e-fbb6f4a2d7b1" TYPE="btrfs"

/dev/sda10: UUID="cad1d000-7ecd-453d-bb3e-c28790d85bee" TYPE="swap"

/dev/sda11: UUID="6d721972-8566-409e-b796-c1429d7670b0" TYPE="crypto_LUKS"

/dev/sdb1: LABEL="mydocuments" UUID="0AAACA9649E772A8" TYPE="ntfs"

/dev/sdb2: UUID="697d8f2a-4d77-4a4c-b48a-a90a525e31b1" TYPE="ext4"

/dev/mapper/secret-disk: UUID="a6fca341-8e25-463b-8e67-7b6a1fdc82c7" TYPE="ext4"

Diagnostic information B:

thebiz@thebizbot:~$ sudo cryptsetup luksFormat /dev/sda6

WARNING!

========

This will overwrite data on /dev/sda6 irrevocably.

Are you sure? (Type uppercase yes): YES

Enter passphrase:

Verify passphrase:

thebiz@thebizbot:~$ cat /etc/crypttab

swapcrypt /dev/sda11 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256

secret-disk UUID=6d721972-8566-409e-b796-c1429d7670b0 none luks

adamherst

I can't answer your specific questions, but when I was working through this lab I made a note that the fstab entry in step 5.b) was incorrect. As per the fstab man page:

The second field (fs_file).
This field describes the mount point for the filesystem. For
swap partitions, this field should be specified as `none'. If
the name of the mount point contains spaces these can be escaped
as `\040'.

So, the line should be:

/dev/mapper/swap none swap defaults 0 0

not

/dev/mapper/swap swapcrypt swap defaults 0 0

Thanks,

Adam

thebiz

Hi Adam,
Thanks for your useful input. I had not noticed the problematic fstab entry.
Tomorrow, I shall test your fstab entry with the Lab 10.2 Solution.
Thereafter, I should be able to answer my second question independently.
Have a nice weekend!
Thanks,
John

coop

This is a red herring. You don't have to say "none"; the field
is ignored, you could substitute "adam" for none. It just indicates
a filesystem which does not have a real device node, a pseudo-filesystem

thebiz

Some more intriguing but nonetheless inconclusive diagnostics that leaves me pulling out more of my hair:

:~$ sudo cryptsetup luksUUID /dev/sda11
6d721972-8566-409e-b796-c1429d7670b0

...Returns the UUID of my encrypted secret partition.

:~$ cat /etc/crypttab
cryptswap /dev/sda6 /dev/urandom swap
secret-disk UUID=6d721972-8566-409e-b796-c1429d7670b0 none luks

... Shows the UUID of secret-disk & the declaration of /dev/sda6 as the source for swap.

:~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/dm-0 partition 2097148 0 -1

... Shows that swap is active.

thebiz@thebizbot:~$ sudo cryptsetup luksUUID /dev/sda6
Device /dev/sda6 is not a valid LUKS device.

BUT!!!! /dev/sda6 is not valid???!!!

Thanks and have a nice weekend.

thebiz

Hi,

I've got a LUKS encrypted partition persistently working across reboot. Its a partial solution since I have been unable to get /dev/random to work so it works with a fixed passphrase prompted at boot. I also have it working with UUID= which is advantageous since my internal HDD and USB HDD are identical disk models so frequently exchange identities (sdaXX or sdbXX).

According to the crypttab manpage; "The third field, key file,...It can also be a device name (e.g. /dev/urandom), note however that LUKS requires a persistent key and therefore does not support random data keys" - Suggesting that random keys may not be supported.

Since, the 10.2 instructions work up until reboot I followed all instructions from the 10.2 Lab Solution but used the following following fstab and crypttab entries:
/etc/crypttab
swapcrypt UUID=aac8a921-c931-4ad6-ae9f-fda79dee00bf none luks
/etc/fstab
/dev/mapper/swapcrypt none swap defaults 0 0

The alternative solution I proposed at the beginning of this thread is not a valid solution. While it appears to start an encrypted swap partition it is not a LUKS encrypted partition and seems to do something questionable with the disk partition itself since it becomes invisible to sudo blkid.

adamherst

I've been playing around trying to figure out the relationship between /dev/urandom vs none in the third field and swap vs luks in the fourth field. Based on the information in the crypttab man pages on both Ubuntu 14.04 and CentOS 7 (they differ slightly but don't contradict each other) I've discovered that a crypttab entry of:

swapcrypt /dev/sdb1 /dev/urandom swap

will create a plain (not LUKS) encrypted swap file that is mounted at boot without prompting for a password. This would seem to be most useful on a server which may have to be rebooted remotely. The only caveat is that a UUID cannot be used since the swap keyword causes mkswap to be run on each reboot which changes the UUID. This drive does not have to be prepared with cryptsetup. In fact, I had to remove the LUKS signature using wipefs to get this to work.

Next on my list is to try to get the --key-file keyword working in order to mount arbitrary LUKS encrypted drives at boot without being prompted for a password. There's a lot of chatter about how to do this on the internet but none of it has worked for me so far. If anyone can point me in the right direction it would be appreciated.

Thanks,

Adam

thebiz

Hi Adam,
Just a thought but since the swap partition is used for system resume having a random key passphrase might not be a very good idea since it could lead to unforeseen consequences? A frequently changed passphrase in a file might be a safer secure proposition in the long term.
Cheers,
John

adamherst

I hadn't considered that. The system I want to secure is my server and it never sleeps/suspends. It just sometimes has to be rebooted. I want to be able to reboot it without having to be at the physical console.

In the meantime, I figured out how to use a keyfile with cryptsetup. That lets me use LUKS to encrypt and a UUID to identify the device and have it mount without prompting at boot. The crypttab entry is:

swapcrypt UUID=39fbce50-9a0f-41e7-9cfd-0b8c2fa5a963 /root/swapcrypt.keyfile luks

The UUID is not the UUID of the swap filesystem given by mkswap but the LUKS UUID obtained with:

sudo cryptsetup luksUUID /dev/sdb1

The keyfile had to be added with:

sudo cryptsetup luksAddKey /dev/sdb1 /root/swapcrypt.keyfile

I made swapcrypt.keyfile only readable by root but I'm not sure how secure this really is. If someone removes the hard drive from my server and mounts it on another system, I think they'll be able to read the password and mount the encrypted volumes. Am I missing something?

Thanks,

Adam

thebiz

Hi Adam,
I would imagine that the LUKS developers removed random key support because of the lock out risk particularly with the resume function. I think ensuring the physical security of your server is the better bet. I'd love to hear Jerry's comments on the subject.
Cheers,
John