Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?

[Sven Hartge <sven@svenhartge.de>]

~Stack~ <i.am.stack@gmail.com> wrote:
> On 03/28/2015 02:15 PM, David Wright wrote: Quoting ~Stack~ (i.am.stack@gmail.com):

>>> $ grep swap /etc/crypttab
>>> # causes systemd to fsck swap
>>> #sda3_crypt UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e /dev/urandom
>>> cipher=aes-xts-plain64,size=256,swap
>>> # systemd doesn't fsck swap
>>> sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap
>> 
>> That cure looks retrograde to me because it throws away the uniqueness
>> of UUIDs. What if /dev/sda3 changes, for whatever reason.
>> 
>> A systemd 216 man page for crypttab says:
>>    "WARNING: Using the swap option will destroy the contents of the
>>    named partition during every boot, so make sure the underlying
>>    block device is specified correctly."
>> 
>> Could you not try using a /dev/disk/by-foo/... entry instead and see
>> if that works? (I don't recognise the particular one Sven uses.)

> Ohhhh....Good catch! That completely blitzed my mind. I knew there was a
> reason for the UUID's! :-)

> In my /dev/disk/by-id/ directory I have both "dm-name-sda3_crypt" and
> "dm-uuid-CRYPT-PLAIN-sda3_crypt" which point to "../../dm-1". I can
> not use either of those in my /etc/crypttab because then I get the
> systemd.fsck problem again. 

Those device nodes only appear _after_ /etc/crypttab has been parsed. By
using them inside the crypttab, you create a chicken-and-egg problem.

> Maybe that was the problem with the UUID??

I guess, you used the UUID of the swap inside the crypted device. But this
UUID changes on every boot, so it is of no use.

> However, I also have "ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3" and
> "wwn-0x10001354922489237504x-part3" that point to "../../sda3". Both of
> those will boot correctly and mount swap. Here is my update that works:
> ----
> sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3
> /dev/urandom cipher=aes-xts-plain64,size=256,swap
> ----

Of course. /etc/crypttab needs the device on which to create the crypted
device mapping.

> So my guess, if I understand this correctly, is that if I use the
> encrypted container, systemd.fsck freaks out, tries to and fails to
> mount, then just ignores swap altogether. However, if I tell LUKS to
> encrypt the actual partition, that somehow means systemd.fsck is happy
> with it. So bizarre.

No, not bizzare at all, quite logic if one thinks about what layer is
put on top of what other layer.

You have /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 at the
bottom. On top of that, you get /dev/mapper/sda3_crypt. And on top of
that you get your swap-space.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.