systemd crypttab fix

[Trammell Hudson]

Is it possible to back port the one line systemd fix from v227 to Qube's
v222 for the problem with parsing LUKS keyfile parameters? The symptom is
that if "rd.luks.key=/secret.key" is specified on the kernel command line
systemd-cryptseutp-generator reports "Out of memory" due to a mistake
how it handles the return code from free_and_strdup().

The bug goes back to 2013:

https://bugzilla.redhat.com/show_bug.cgi?id=905683

And was patched in Sep 2015 in systemd:

https://github.com/systemd/systemd/commit/c802a7306bdc3e82378a87acd9402bbabe9f6b28

We discussed it briefly on the qubes-devel list a few months ago,
although I don't think there was any decision. I've just updated my
machine with qubes-dom0-update and it looks like systemd is
unchanged since then.

--
Trammell

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Trammell,

Did you try the "rd.luks.key=LUKSUUID=KEYFILE" workaround? IIRC, this
shouldn't trigger the buggy if branch.

> Is it possible to back port the one line systemd fix from v227 to Qube's

> v222 for the problem with parsing LUKS keyfile parameters? [...]

> I've just updated my
> machine with qubes-dom0-update and it looks like systemd is
> unchanged since then.

Qubes R3.2 uses systemd from the Fedora 23 repository, which is EOL, so
backporting a patch would entail importing systemd into a Qubes dom0
package repository first. Now that systemd is effectively frozen, maybe
that's feasible (if it turns out the workaround doesn't do the trick).

Marek, what do you think about building a one-off systemd package in
qubes-dom0-unstable, if given a patch to the final f23 .spec file?

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJY4tjqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf/iMP/15LaX8Hq8yGipimSaZ3Q/dK
NsFu1gLNL33eaZix0+B6uad4/NN28zXWhnxJEWXVMmF7zXVVzhsEKkGo/aMVrj03
VAkPrqzMxrr506j9LMogH+7/9hKQQZ4dumwumkXeNbyz5l29maRU2rdC0+bl2EDU
mXfNEdIHjaG7ktBXO/M+Vb+DIhDo2hTUsOFQJ/tK6HRnYZB2XkhIR41YuSgFqbzm
t4HzL8NWuo5uh5atVGJujSz8cOAcO5P1piMFr0wN6Ra8x5p8y0JO9Xp8TDvislD0
XMzCtusyIe/rxh3dxCS8qcT9BFIyeSSiBMjMQ9VicMAs7ZcK5//IPGrzIC6r8XC8
3lFtS399ZW8CP0p59AdbU/GBg8ugS7kpN6lzxHeLPfDh5C2oG3DOtvUzUJcQpLdz
jQ976Vly7LOfpZkwadtO/DCaLI1gUQdOHxLCTAiGXC9fGRiTRQMab0y0kNLxB0R3
n76SVpZsi878ORzz1W2z2hBRF+0pBkMturbISS0H1kU3UfR0ZG0X7nu9cwz5W//D
fhG37F0tCtNBHWuCOx/3UTcdg+wYyfcX+vYaYW7IFYScCXNm+kpx2Xzaml5dekq/
2C3xRkOXylHknVeuS/U/tCl58Y88xqc8sn8LsBKJyuX3ORFXwqqlWnWcqsKMarJs
hrZUaUEUkmUxHQvT+nXl
=7nyt
-----END PGP SIGNATURE-----

[Trammell Hudson]

On Mon, Apr 03, 2017 at 11:21:14PM +0000, Rusty Bird wrote:
> Did you try the "rd.luks.key=LUKSUUID=KEYFILE" workaround? IIRC, this
> shouldn't trigger the buggy if branch.

I haven't tried that one, although I did build a patched version of
systemd v227 with the fix applied and found another problem --
it seem to only apply the keyfile to the root device and prompts for a
password for the other partitions.

So as a workaround I'm generating a /etc/cryptab that specifies
/secret.key for every paritition and inserting those two files into
the initrd at boot time. This works, although the rebuilding the cpio
is slow.

What controls the generate of /etc/crypttab in the initrd during a
system upgrade? Would it be possible to have it create the correct
entries for all the partitions instead?

--
Trammell

[Ivan Mitev]

On 04/04/2017 03:13 AM, Trammell Hudson wrote:
> On Mon, Apr 03, 2017 at 11:21:14PM +0000, Rusty Bird wrote:
>> Did you try the "rd.luks.key=LUKSUUID=KEYFILE" workaround? IIRC, this
>> shouldn't trigger the buggy if branch.
>
> I haven't tried that one, although I did build a patched version of
> systemd v227 with the fix applied and found another problem --
> it seem to only apply the keyfile to the root device and prompts for a
> password for the other partitions.
>
> So as a workaround I'm generating a /etc/cryptab that specifies
> /secret.key for every paritition and inserting those two files into
> the initrd at boot time. This works, although the rebuilding the cpio
> is slow.

I did something like that on a centos7 install. I'm wondering what you
mean by "inserting those two files" - in my case the only I've done is
to create a .conf file in /etc/dracut.conf.d containing this single line:

install_items+=/etc/blah/key

The key path being of course the same as the one defined in
/etc/crypttab ; that way the key file gets included automatically each
time dracut creates a new initrd - usually at each kernel update.

Judging by your former posts (very interesting BTW !) I guess you
probably have a more custom setup an my solution may not apply but I
thought I'd post it anyway :)

Cheers
Ivan

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Apr 03, 2017 at 06:13:38PM -0600, Trammell Hudson wrote:
> On Mon, Apr 03, 2017 at 11:21:14PM +0000, Rusty Bird wrote:
> > Did you try the "rd.luks.key=LUKSUUID=KEYFILE" workaround? IIRC, this
> > shouldn't trigger the buggy if branch.
>
> I haven't tried that one, although I did build a patched version of
> systemd v227 with the fix applied and found another problem --
> it seem to only apply the keyfile to the root device and prompts for a
> password for the other partitions.

I've just checked that dom0 in Qubes 4.0 (based on fc25) have systemd
231. Not sure if the above still apply...

> So as a workaround I'm generating a /etc/cryptab that specifies
> /secret.key for every paritition and inserting those two files into
> the initrd at boot time. This works, although the rebuilding the cpio
> is slow.
>
> What controls the generate of /etc/crypttab in the initrd during a
> system upgrade? Would it be possible to have it create the correct
> entries for all the partitions instead?

As Ivan already mentioned, I'd go with "install_items" option
(/etc/dracut.conf.d/something.conf). See dracut.conf(5). Or maybe a
trivial dracut module - you could use source location different than
destination then. I don't a config equivalent for dracut --include
option.
Answering your question -
/usr/lib/dracut/modules.d/90crypt/module-setup.sh

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY40GcAAoJENuP0xzK19csIaEIAIlx13XU0qFEfOWONMLIkY34
HFNlAXTVOo/EXtuL5PYBeaHAS5TxqQzG/wjDm0EceNnQ74Z28YBsrY7wWbUlJbxK
EDxd//5UZw4dSU5SLZIWRNqTOHgT41NlXu5SzdaqZS0FVT9VbH6+SPQxsNlriubb
lZTxfmK2PYze/GDJvAOlGUT4mxgZh6fms6kNfLWco63K+ZKq1XhaCAZsb1tcv6Fu
MPhq4NOXNTPvQSAjykQi2xhdvCkwhQWsIPX5UfNocGvSCbnzA0foF2Yxk3iw0nMt
H6o56snOAltqvH7mdvbq2G6qbeGlCcS4bKT/GAqGoGcVC+SDHRe62/j5sw6cbCw=
=AyiG
-----END PGP SIGNATURE-----

[Trammell Hudson]

On Tue, Apr 04, 2017 at 08:47:55AM +0200, Marek Marczykowski-Górecki wrote:
> [...]

> Answering your question -
> /usr/lib/dracut/modules.d/90crypt/module-setup.sh

That's super helpful, thanks, and gets me almost all of the way there
without having to touch systemd.

If I edit the dom0 /etc/crypttab file to change "none" to "/secret.key"
for the three partitions (/, /home and swap) and run "sudo dracut --force",
the initramfs /etc/crypttab will be generated with the keyfile specified
for / and swap, but not for /home.

It looks like the "filter for the devices we need" part of module-setup.sh
is discarding /home, which prevents the system from booting without
a passphrase. If I comment out the test "$_hdev -ef $_dev" it will
include all three partitions in the initrd /etc/crypttab and the
system boots fine.

--- module-setup.sh.orig 2017-04-04 18:06:12.246999989 -0400
+++ module-setup.sh 2017-04-04 18:06:17.491999981 -0400
@@ -75,7 +75,7 @@

for _hdev in "${!host_fs_types[@]}"; do
[[ ${host_fs_types[$_hdev]} == "crypto_LUKS" ]] || continue
- if [[ $_hdev -ef $_dev ]] || [[ /dev/block/$_hdev -ef $_dev ]]; then
+ if true || [[ $_hdev -ef $_dev ]] || [[ /dev/block/$_hdev -ef $_dev ]]; then
echo "$_mapper $_dev $_rest"
break
fi
--
Trammell

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Apr 04, 2017 at 04:08:38PM -0600, Trammell Hudson wrote:
> On Tue, Apr 04, 2017 at 08:47:55AM +0200, Marek Marczykowski-Górecki wrote:
> > [...]
> > Answering your question -
> > /usr/lib/dracut/modules.d/90crypt/module-setup.sh
>
> That's super helpful, thanks, and gets me almost all of the way there
> without having to touch systemd.
>
> If I edit the dom0 /etc/crypttab file to change "none" to "/secret.key"
> for the three partitions (/, /home and swap) and run "sudo dracut --force",
> the initramfs /etc/crypttab will be generated with the keyfile specified
> for / and swap, but not for /home.
>
> It looks like the "filter for the devices we need" part of module-setup.sh
> is discarding /home, which prevents the system from booting without
> a passphrase. If I comment out the test "$_hdev -ef $_dev" it will
> include all three partitions in the initrd /etc/crypttab and the
> system boots fine.

Can you try just including /etc/crypttab as "install_items" config
option? I'm not sure about the priorities here, but if that works after
90crypt, it should be even better.

> --- module-setup.sh.orig 2017-04-04 18:06:12.246999989 -0400
> +++ module-setup.sh 2017-04-04 18:06:17.491999981 -0400
> @@ -75,7 +75,7 @@
>
> for _hdev in "${!host_fs_types[@]}"; do
> [[ ${host_fs_types[$_hdev]} == "crypto_LUKS" ]] || continue
> - if [[ $_hdev -ef $_dev ]] || [[ /dev/block/$_hdev -ef $_dev ]]; then
> + if true || [[ $_hdev -ef $_dev ]] || [[ /dev/block/$_hdev -ef $_dev ]]; then
> echo "$_mapper $_dev $_rest"
> break
> fi

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY5B8ZAAoJENuP0xzK19csKGAH/1hTUtGpp++SLmwzmUaLavek
EmEG9kJQkyhw/wpiw5lCSMPKdJ43JzBS0PvrPk5rGfOayt7Hb3Zw5jNh0e8mk7LZ
ieuJ6e3BTLAtQZTVRYQ3ZDiL50b2iWUWwwMg9IUTkPfdaji8tjNr2tfZaG/1ueZx
O4C6Wv5a6J+kGRn5yi20703ZkDn32CvHzEj9NKVI+rfyJLQWJT22j/EG5/T+C5y9
jIvP1TmODk/hvxehqAhNq4XPDFEqjhn6FOTkVoSrN9Kit8xFG+5SirOA7cTHqHc1
CVkOHAFdR19sYjq/17UoodG1tsD6jrvhkoswt/00hDVUcJYLvJDTgnuIgPhK3hY=
=HfF2
-----END PGP SIGNATURE-----