Bug#618862: systemd: ignores keyscript in crypttab

[Michael Niewöhner]

Hi all,

I stumbled on this, too but I have a work-around for at least 'decrypt_keyctl'.

systemd uses systemd-cryptsetup -> systemd-ask-password -> linux keyring.
The keyring can be modified by keyctl just as 'decrypt_keyctl' does.
As I wanted to use 'decrypt_keyctl' for unlocking root and data with the same
password, I applied this patch:

--- /lib/cryptsetup/scripts/decrypt_keyctl.distrib  2017-05-09
13:50:59.0 +0200
+++ /lib/cryptsetup/scripts/decrypt_keyctl  2018-08-04 21:34:01.130979945
+0200
@@ -24 +24 @@ die()
-ID_="cryptkey-$1"
+ID_="cryptsetup"

My entries in crypttab are these:
crypt_sys /dev/zpool_sys/zvol_sys none luks,discard,keyscript=decrypt_keyctl
crypt_data /dev/zpool_data/zvol_data none luks,discard,keyscript=decrypt_keyctl

Now cryptsetup-initramfs unlocks my root device and decrypt_keyctl caches the
password to linux keyring with desc=cryptsetup.

Systemd then reads the key from keyring with desc=cryptsetup and unlocks my data
 device! :-)

That keyring caching could be easily added to all other keyscripts to make
systemd unlock work ;-)


Best regards
Michael

Bug#618862: systemd: ignores keyscript in crypttab

[Michel Messerschmidt]

>  > Workaround: add "luks=no" to the kernel command line to disable
> systemd's generator
> 
> This worked great... until you try to add another partition to crypttab.
> Since the cryptroot in initrd only does root, but luks=no disables all
> others.
> 
> Is there any clean solution that recognizes the granularity? Maybe one way
> is to put all encrypted filesystems loaded via initramfs?

Not a clean solution, but a workaround for root partitions using a keyscript.

Let systemd handle encrypted partitions via crypttab (i.e. don't use luks=no).
But exclude the root partition by masking the generated unit.

 Example
-
My crypttab contains (among other entries):
root_crypt   UUID=----  
/dev/disk/by-uuid/----:/keys/root  
luks,keyscript=passdev

systemd will dynamically generate service units for all partitions in crypttab:
$ ls -l /run/systemd/generator/systemd-cryptsetup*
-rw-r--r-- 1 root root  867 Feb  2 16:31 
/run/systemd/generator/systemd-cryptsetup@home_crypt.service
-rw-r--r-- 1 root root 1103 Feb  2 16:31 
/run/systemd/generator/systemd-cryptsetup@root_crypt.service
-rw-r--r-- 1 root root  865 Feb  2 16:31 
/run/systemd/generator/systemd-cryptsetup@var_crypt.service

Whenever systemd tries to start systemd-cryptsetup@root_crypt.service during 
boot, it will timeout and fail.
Feb 02 13:52:39 host systemd[1]: Timed out waiting for device 
dev-disk-by\x2duuid-\x2d\x2d\x2d\x2d:-keys-root.device.
Feb 02 13:52:39 host systemd[1]: Dependency failed for Cryptography Setup for 
root_crypt.
Feb 02 13:52:39 host systemd[1]: Dependency failed for Local Encrypted Volumes.
Feb 02 13:52:39 host systemd[1]: cryptsetup.target: Job cryptsetup.target/start 
failed with result 'dependency'.
Feb 02 13:52:39 host systemd[1]: systemd-cryptsetup@root_crypt.service: Job 
systemd-cryptsetup@root_crypt.service/start failed with result 'dependency'.


But the following command will mask this unit, so that systemd will not attempt 
to start at all:
systemctl mask systemd-cryptsetup@root_crypt.service

Afterwards, my system boots without timeout and all encrypted partitions are 
available.


HTH,
Michel
-- 
Security is not a product and not a process. Security is an emotion.

Bug#618862: systemd: ignores keyscript in crypttab

[Bruno Bierbaumer]

Package: systemd
Version: 231-4
Followup-For: Bug #618862

Hello,
I also run into this issue while trying to mount 2 disks (LUKS + VeraCrypt) 
encrypted with the same passphrase during boot.
Is there any progress on this bug?

Greetings,
Bruno

-- Package-specific info:


*** reportbug-systemd-20160907-1006-qZ2Gk_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Bruno Bierbaumer 
To: Debian Bug Tracking System <618...@bugs.debian.org>
Subject: Re: systemd: ignores keyscript in crypttab
Message-ID: <147327319493.1006.14100880853937122454.report...@pc.lan>
X-Mailer: reportbug 6.6.6
Date: Wed, 07 Sep 2016 20:33:14 +0200

Package: systemd
Version: 231-4
Followup-For: Bug #618862

Hello,
I also run into this issue while trying to mount 2 disks (LUKS + VeraCrypt) 
with the same passphrase during boot.
Is there any progress on this bug?

Greetings,
Bruno


-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-4
ii  libaudit1   1:2.6.6-1
ii  libblkid1   2.28.1-1
ii  libc6   2.23-5
ii  libcap2 1:2.25-1
ii  libcap2-bin 1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.7.3-1
ii  libgpg-error0   1.24-1
ii  libidn111.33-1
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.28.1-1
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2
ii  libselinux1 2.5-3
ii  libsystemd0 231-4
ii  mount   2.28.1-1
ii  util-linux  2.28.1-1

Versions of packages systemd recommends:
ii  dbus1.10.10-1
ii  libpam-systemd  231-4

Versions of packages systemd suggests:
ii  policykit-10.105-16
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  231-4

-- no debconf information


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-4
ii  libaudit1   1:2.6.6-1
ii  libblkid1   2.28.1-1
ii  libc6   2.23-5
ii  libcap2 1:2.25-1
ii  libcap2-bin 1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.7.3-1
ii  libgpg-error0   1.24-1
ii  libidn111.33-1
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.28.1-1
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2
ii  libselinux1 2.5-3
ii  libsystemd0 231-4
ii  mount   2.28.1-1
ii  util-linux  2.28.1-1

Versions of packages systemd recommends:
ii  dbus1.10.10-1
ii  libpam-systemd  231-4

Versions of packages systemd suggests:
ii  policykit-10.105-16
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  231-4

-- no debconf information

Bug#618862: systemd: ignores keyscript in crypttab

[guenther kuenzel]

maybe i should have given more details about my suggested solution.


create your partitions as usual, but create one partition big enough to
store all your encrypted data:

/dev/sda1 -> /boot
/dev/sda2 -> all encrypted data
...

encrypt the desired partition:

cryptsetup ... create encrypted-sda2 /dev/sda2

put LVM on the encrypted device:

pvcreate ... /dev/mapper/encrypted-sda2
vgcreate ... encrypted-volume /dev/mapper/encrypted-sda2

create your logical volumes for your encrypted needs:

lvcreate ... --name encrypted-root encrypted-volume
lvcreate ... --name encrypted-swap encrypted-volume

now you are able to add a single entry into crypttab while having
multiple logical volumes encrypted

Bug#618862: systemd: ignores keyscript in crypttab

[guenther kuenzel]

the only clean solution that i have found so far. put the encryption on
the blockdevice and use LVM for partitioning. if you have multiple
disks, use software raid, encryption on the raid blockdevice and LVM for
partitioning. that is only a workaround which prevents the requirement
to define multiple devices in crypttab, but still being able to encrypt
multiple volumes.

cryptsetup with keyscript and multiple encrypted devices does not work
for me.

greetings

Bug#618862: systemd: ignores keyscript in crypttab

[Avi Deitcher]

 > Workaround: add "luks=no" to the kernel command line to disable
systemd's generator

This worked great... until you try to add another partition to crypttab.
Since the cryptroot in initrd only does root, but luks=no disables all
others.


E.g. if crypttab looks like

root /dev/sda1 /dev/sda5:/keyfile rootdev,keyscript=/path/to/some/keyscript
swap /dev/sda2 /dev/urandom swap

then you are stuck:

1. luks=no: systemd doesn't try to reopen /dev/sda1 (GOOD), but it also
doesn't try to enable swap (BAD)
2. comment out root from crypttab: systemd doesn't try to reopen /dev/sda1
(GOOD), but it then needs a mess of kernel command-line options in grub.cfg
(BAD), and it doesn't install the necessary binaries to initramfs (BAD).

Is there any clean solution that recognizes the granularity? Maybe one way
is to put all encrypted filesystems loaded via initramfs?



-- 
Avi Deitcher
a...@deitcher.net
Follow me http://twitter.com/avideitcher
Read me http://blog.atomicinc.com

Bug#618862: systemd: ignores keyscript in crypttab

[Rick Thomas]

I tested Marcello’s workaround.  It works!  That’s wonderful!  Thank you so 
much, Marcello!

Now some further thoughts on the subject…

It’s a workaround for this bug, but, unfortunately it’s just a workaround not a 
real fix.  In particular, using a “luks=no” kernel command line option disables 
all luks encryption that is not unlocked in the initrd phase.  Decryption that 
waits until we’re out of the initrd is a less common use-case, but nevertheless 
a legitimate one.

A better work around would be to recognize the (documented but not currently 
working under systemd) crypttab option “noearly” — which prevents attempts to 
decrypt when in initrd — and a new (not currently documented or implemented) 
option “earlyonly” — which specifies that decryption for this item must occur 
while in initrd and should not be attempted outside of initrd.

But even that’s just a workaround.  A true _fix_ would be to never attempt to 
decrypt any item has already been successfully decrypted by an earlier stage.

Enjoy!
Rick

 
On Oct 18, 2015, at 4:17 AM, Marcello Barnaba  wrote:

> 
>>> Does this work for encrypted root as well?
> 
>> FTR, systemd isn't involved in unlocking the root file system, that
>> already (has to) happen in the initramfs. So this can only affect
>> non-root file systems.
> 
> With the setup I've detailed above (encrypted LUKS root
> unlocked via the passdev keyscript) I see autogenerated
> systemd units trying to setup an *already mounted root*.
> Same for encrypted swap, already set up in initramfs.
> 
> The units wait and time out after 90 seconds, causing a
> noticeable boot delay. Adding "luks=no" (or rd.luks=no)
> disables the generator and the delay.
> 
> If you need more details or information other than what I've
> provided above please let me know.
> 
> Thanks,
> 
> ~Marcello
> -- 
> ~ v...@openssl.it
> ~ http://sindro.me/
> 
> -- 
> To unsubscribe, send mail to 618862-unsubscr...@bugs.debian.org.
> 

Bug#618862: systemd: ignores keyscript in crypttab

[Marcello Barnaba]

>> Does this work for encrypted root as well?

> FTR, systemd isn't involved in unlocking the root file system, that
> already (has to) happen in the initramfs. So this can only affect
> non-root file systems.

With the setup I've detailed above (encrypted LUKS root
unlocked via the passdev keyscript) I see autogenerated
systemd units trying to setup an *already mounted root*.
Same for encrypted swap, already set up in initramfs.

The units wait and time out after 90 seconds, causing a
noticeable boot delay. Adding "luks=no" (or rd.luks=no)
disables the generator and the delay.

If you need more details or information other than what I've
provided above please let me know.

Thanks,

~Marcello
-- 
~ v...@openssl.it
~ http://sindro.me/

Bug#618862: systemd: ignores keyscript in crypttab

[Martin Pitt]

Rick Thomas [2015-10-16  8:40 -0700]:
> Does this work for encrypted root as well?

FTR, systemd isn't involved in unlocking the root file system, that
already (has to) happen in the initramfs. So this can only affect
non-root file systems.

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#618862: systemd: ignores keyscript in crypttab

[Marcello Barnaba]

> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
> my root and swap partition are encrypted with cryptsetup; root uses a custom
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all

I confirm the same problem albeit while using the passdev keyscript.

Workaround: add "luks=no" to the kernel command line to disable systemd's 
generator: 
http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html

Debian Jessie *supports* keyscripts, as long as faulty software is disabled.

~Marcello
-- 
~ v...@openssl.it
~ http://sindro.me/

Bug#618862: systemd: ignores keyscript in crypttab

[Rick Thomas]

On Oct 16, 2015, at 3:02 AM, Marcello Barnaba  wrote:

>> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
>> my root and swap partition are encrypted with cryptsetup; root uses a custom
>> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
>> systemd seems to be unable to work with keyscripts at all
> 
> I confirm the same problem albeit while using the passdev keyscript.
> 
> Workaround: add "luks=no" to the kernel command line to disable systemd's 
> generator: 
> http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
> 
> Debian Jessie *supports* keyscripts, as long as faulty software is disabled.
> 
> ~Marcello

Marcello,

Does this work for encrypted root as well?  Or is it only for things like swap 
and /home that can wait until after switching out of initramdisk?
If it works for encrypted root, this is genuinely good news!


Thanks!
Rick

Bug#618862: systemd: ignores keyscript in crypttab

[Marcello Barnaba]

>> Workaround: add "luks=no" to the kernel command line to disable systemd's 
>> generator: 
>> http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html

> Does this work for encrypted root as well?  Or is it only for things like 
> swap and /home that can wait until after switching out of initramdisk?
> If it works for encrypted root, this is genuinely good news!

Yes. I'm using passdev in initramfs at the scripts/local-top
stage as per cryptsetup docs to mount an encrypted root,
unlocking it via a keyfile located on an USB key.

/etc/crypttab:

  # dev source keyfile opts
  root /dev/sda2 /dev/disk/by-label/keys:/rootkey luks,keyscript=passdev

Then, update-initramfs -u

/dev/sda2 set up using cryptsetup luksFormat. No LVM.
Working on current Kali Linux, based on Jessie/sid.
Sorry I don't have version numbers at hand.

HTH, YMMV! :)

~Marcello
-- 
~ v...@openssl.it
~ http://sindro.me/

Bug#618862: systemd: ignores keyscript in crypttab

[Rick Thomas]

On Oct 16, 2015, at 9:20 AM, Marcello Barnaba  wrote:

> 
>>> Workaround: add "luks=no" to the kernel command line to disable systemd's 
>>> generator: 
>>> http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
> 
>> Does this work for encrypted root as well?  Or is it only for things like 
>> swap and /home that can wait until after switching out of initramdisk?
>> If it works for encrypted root, this is genuinely good news!
> 
> Yes. I'm using passdev in initramfs at the scripts/local-top
> stage as per cryptsetup docs to mount an encrypted root,
> unlocking it via a keyfile located on an USB key.
> 
> /etc/crypttab:
> 
>  # dev source keyfile opts
>  root /dev/sda2 /dev/disk/by-label/keys:/rootkey luks,keyscript=passdev
> 
> Then, update-initramfs -u
> 
> /dev/sda2 set up using cryptsetup luksFormat. No LVM.
> Working on current Kali Linux, based on Jessie/sid.
> Sorry I don't have version numbers at hand.
> 
> HTH, YMMV! :)
> 
> ~Marcello

Woo Hoo!  I can’t wait to test it!  (-: (-: (-:

Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[David Härdeman]

On 2015-05-26 00:05, Alberto Bertogli wrote:
I hit this issue after upgrading a system that used keyscript to 
Jessie,

and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, 
and/or

creating a generic one that would invoke keyscripts as a workaround...



...

On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:

On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
 b) the password agent implementation in systemd doesn't seem to
 handle binary strings (i.e. strings with '\0'), as can be seen by
 calls to e.g. strlen()...

 Whether making it binary safe would be a major change or not is
 something I haven't researched yet but it seems like a change that
 should be generally useful upstream...

I'd be OK with this, as discussed at FOSDEM, and I see you already
posted a ptach for this.


Has this been merged?


No, the last word was basically this thread:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021246.html

I don't have the time to implement a complete solution...


Is it safe for a password agent to write content with \0 back to the
socket?


Haven't checked but I'd be surprised if that was the case.

//David


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[Alberto Bertogli]

I hit this issue after upgrading a system that used keyscript to Jessie,
and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, and/or
creating a generic one that would invoke keyscripts as a workaround...


On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
 On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
 
  a) getting the name of the cryptdev that the password request
  corresponds to currently involves parsing the prompt message
  (Please enter passphrase for disk %s!) which is obviously not a
  real solution...
  
  This issue is fixable with minor upstream changes, e.g. by extending
  the PasswordAgent protocol to add Subsystem=cryptsetup and
  Target=diskname entries to the ask. file.
 
 I'd be fine with adding a field Id= or so, which then is filled by an
 identifier of some kind be the cryptsetup tool that is useful to
 identify the device to query things on. for example:
 Id=cryptsetup:/dev/sda5 or so could be one way how this could be
 filled in. We wouldn't enfoce any kind of syntax on this, just suggest
 some common sense so that people choose identifiers that are unlikely to
 clash with other subsystems, and somewhat reasonable to read...

... and I ran into a problem with this, because in practise this field
can look like:

  Id=cryptsetup:ST1234AB567-1CD234 (cbackups) on /var/backups/

for a crypttab line like:

  cbackups /dev/disk/by-id/ata-ST1234AB567-1CD234_1XY2ZWAB-part2 cbackups 
luks,keyscript=/usr/bin/kxc-cryptsetup


because it comes from the name, which seems to be constructed for
human consumption, at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n596

So a password agent _still_ needs to resort to brittle parsing of the
Id field in order to find the corresponding crypttab entry.


Would changing get_password() to take an additional id, which would be
the volume name (argv[2]), and use that for the ask_password_auto() id,
be ok with you?

That would allow password agents to have a reliable id to work with
without doing brittle parsing, and matching what's in crypttab.


In theory, existing code should not need to adjust to the change, as the
proposed change is already a possibility when neither the mount point or
description are available, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n607
I don't know of any password agents to verify in practise, though.



  b) the password agent implementation in systemd doesn't seem to
  handle binary strings (i.e. strings with '\0'), as can be seen by
  calls to e.g. strlen()...
  
  Whether making it binary safe would be a major change or not is
  something I haven't researched yet but it seems like a change that
  should be generally useful upstream...
 
 I'd be OK with this, as discussed at FOSDEM, and I see you already
 posted a ptach for this.

Has this been merged?

Is it safe for a password agent to write content with \0 back to the
socket?

Thanks!
Alberto


[1]: In case it helps anyone else, I added the initramfs option to
crypttab as a workaround, which works in my case because the script
(kxc) is initramfs-ready.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[GW]

  

Hello, 

In case someone else needs it, a workaround for the common
use case of using the `decrypt_derived` keyscript to unlock partitions
is to save the derived key into a file on the encrypted partition that
you would otherwise derive from (make sure only root can access it).
This at least works for the encrypted root partition on which others
depend on and is as secure as using the decrypt_derived keyscript.


http://gw.tnode.com/debian/issues-and-workarounds-for-debian-8/


Greetings,
 gw  

  

Bug#618862: systemd: ignores keyscript in crypttab

[Brainslug]

Hi,

I'm also affected by this problem. Very simple setup, encrypted root
and swap via decrypt_derived so I can suspend to disk:

/etc/crypttab:
sda5_crypt UUID=2fa9feb8-b096-41f7-bf17-41399ccc8004 none luks
sda4_crypt UUID=6d3382e4-58fc-4f10-9346-276bbc127e78 sda5_crypt
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

In /var/log/syslog:

Mar 11 20:37:38 hercules systemd-cryptsetup[544]: Encountered unknown
/etc/crypttab option
'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.


Any progress on this? I would think this needs to be fixed before jessie
can be released, otherwise a lot of systems out there will break?


Thanks  Cheers!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[Ivan Jager]

On Mon, Mar 30, 2015 at 11:28 AM, Marco d'Itri m...@linux.it wrote:
 I should add some code to preinst to abort the installation if the
 keyscript directive is used in crypttab.

Would that still leave the system in a broken state though? Is preinst
early enough to avoid breakage due to uninstalling other packages?

I guess leaving the system unbootable with warning is a bit better
than without warning, but still...

Out of curiosity, how difficult would it be to have systemd fall back
to using the cryptdisks init scripts if it detects options it doesn't
recognize? Or could it be easily modified to always use the
initscripts until the built in replacement is mature enough to replace
it?

I'm assuming this should be taken with a mountain of salt, but
http://www.freedesktop.org/wiki/Software/systemd/ claims, systemd
supports SysV and LSB init scripts and works as a replacement for
sysvinit.


Ivan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[Marco d'Itri]

On Mar 30, Brainslug brains...@freakmail.de wrote:

 Any progress on this? I would think this needs to be fixed before jessie
 can be released, otherwise a lot of systems out there will break?
While both we and the upstream maintainers believe that continuing to 
support this feature is a good idea, so far acceptable patches have not 
been contributed.
I doubt that such patches will magically appear in a few days, so it 
looks like that jessie will not support keyscripts.

I should add some code to preinst to abort the installation if the
keyscript directive is used in crypttab.

-- 
ciao,
Marco


pgp4ggD8Iz1nZ.pgp
Description: PGP signature

Bug#618862: systemd: ignores keyscript in crypttab

[Michael Biebl]

Am 30.03.2015 um 19:39 schrieb Ivan Jager:
 On Mon, Mar 30, 2015 at 11:28 AM, Marco d'Itri m...@linux.it wrote:
 I should add some code to preinst to abort the installation if the
 keyscript directive is used in crypttab.
 
 Would that still leave the system in a broken state though? Is preinst
 early enough to avoid breakage due to uninstalling other packages?
 
 I guess leaving the system unbootable with warning is a bit better
 than without warning, but still...

Keep in mind, that on upgrades, we retain the sysvinit binary, which you
can boot via the init=/lib/sysvinit/init kernel comman line parameter
for this very reason, i.e. systemd failing to boot your system.
Grub will even automatically create a boot menu for your (it's under
advanced settings)

So maybe, instead of aborting in preinst, we could simply show a warning
in pointing people at that possibility? And telling them, that they can
switch back fully via apt-get install sysvinit-core.

 Out of curiosity, how difficult would it be to have systemd fall back
 to using the cryptdisks init scripts if it detects options it doesn't
 recognize? Or could it be easily modified to always use the
 initscripts until the built in replacement is mature enough to replace
 it?

I don't think this would work. Systemd's mount mechanisms are highly
dynamic and event based. That simply doesn't fit with how the cryptsetup
SysV init script works.

 I'm assuming this should be taken with a mountain of salt, but
 http://www.freedesktop.org/wiki/Software/systemd/ claims, systemd
 supports SysV and LSB init scripts and works as a replacement for
 sysvinit.

For functionality, like cryptsetup, which integrates so deeply in the
boot process, you can't just use the old SysV init scripts, that's correct.

As a rough approximation, every SysV init script which runs in
/etc/rcS.d/ would should ideally be converted to integrate properly.

For SysV init scripts which run in runlevel 2-5, the backwards
compatibility is quite good.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#618862: systemd: ignores keyscript in crypttab

[Mikhail Morfikov]

Source: systemd
Followup-For: Bug #618862

Is there a solution to this issue?

I'm currently using debian sid + sysvinit because I can't switch to systemd.

This is my setup:

root:~# lsblk -f
NAME FSTYPE  LABEL   UUID
MOUNTPOINT
sda
├─sda1   ntfswindows 36442BAC442B6E35
├─sda2   ext4boot4c67dff5-3d8e-4b3f-
9cf1-49b88d5f67a9   /boot
├─sda3   crypto_LUKS 9e03ae84-2f10-4f88-bf1c-
d7507ad30f78
│ └─debian_laptopLVM2_member 1f7G9n-hwJ4-hD20-N9GP-3l77
-8tCi-uM7LZG
│   ├─debian_laptop-root ext4rootdfdc8fb7-d9d4-4cd4-869c-
0f1910a3a17e   /
│   ├─debian_laptop-home ext4home
27632431-fa15-49ba-8354-9c193e321aa6   /home
│   ├─debian_laptop-tmp  ext4tmp be5e9b14-4f41-462a-
b3c6-8502e88cc0c7
│   └─debian_laptop-swap swapc4f58930-bfda-4f4e-
bad0-2be8d1b5bc9e
├─sda4
├─sda5   crypto_LUKS d314ed20-ffaf-
4a18-98a7-91538e79d981
│ └─grafiext4grafi
990d110a-1310-4ab2-8a03-c952a408be11   /media/Grafi
└─sda6   crypto_LUKS f3c10054-0583-4e10-937b-
dcdc9a05a25c
  └─kabi ext4kabib47e6dcd-924e-40fa-
a8b1-7593419f86d7   /media/Kabi

As you can see I have encrypted LVM, which works just fine. I have also two
other
encrypted volumes, and here's the problem. Take a look at /etc/crypttab
and /etc/fstab files:

root:~# egrep -v ^# /etc/crypttab
debian_laptop   UUID=9e03ae84-2f10-4f88-bf1c-d7507ad30f78   noneluks
kabiUUID=f3c10054-0583-4e10-937b-dcdc9a05a25c   debian_laptop
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
grafi   UUID=d314ed20-ffaf-4a18-98a7-91538e79d981   debian_laptop
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,noauto

root:~# egrep -v ^# /etc/fstab

UUID=dfdc8fb7-d9d4-4cd4-869c-0f1910a3a17e   /
ext4defaults,errors=remount-ro,commit=100 1
UUID=4c67dff5-3d8e-4b3f-9cf1-49b88d5f67a9   /boot   ext4
defaults,errors=remount-ro,commit=100 2
UUID=27632431-fa15-49ba-8354-9c193e321aa6   /home   ext4
defaults,errors=remount-ro,commit=100 2
UUID=990d110a-1310-4ab2-8a03-c952a408be11   /media/Grafiext4
defaults,nofail,errors=remount-ro,commit=10 0 2
UUID=b47e6dcd-924e-40fa-a8b1-7593419f86d7   /media/Kabi ext4
defaults,errors=remount-ro,commit=100 2
UUID=c4f58930-bfda-4f4e-bad0-2be8d1b5bc9e   swapswap
defaults,pri=10 0 0

tmpfs /tmp tmpfs defaults,noatime,nosuid,noexec,nodev,mode=1777,size=512M 0 0

Both of the encrypted volumes use decrypt_derived script. I don't want to open
one
of them at boot time, that's why I used also the noauto option.

This setup works, but only with sysvinit. I've been using it for several
years and I've never had a problem with it.
So how can I fix this in order to switch to systemd?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[An Inbox]

Hi,

I have the same issue as Evgeni above in a similar set-up and can 
provide a bit more information. It seems some alignment is needed 
between packages cryptsetup, initramfs-tools and systemd.


In the cryptsetup documentation, there is a README on how to 
configure an encrypted root disk where the decryption key is read from 
another media file, see /usr/share/doc/cryptsetup/README.initramfs.gz 
section 10.
The recommended approach is to use the passdev script (it's 
actually a binary, but makes use of the keyscript feature discussed 
here). This requires putting an entry in /etc/crypttab.
As a good documentation reading user ;) this is what I did, and got 
a set-up like Evgeni. This used to work fine before I switched to 
systemd (on Jessie too), and now I have this same delay at boot.


What happens is that the keyscript/passdev is correctly handled by 
the initramfs tools. They pick up the /etc/crypttab entry, puts 
everything required in the initramfs. And the encrypted root is 
successfully mounted and switched to by the initramfs.


Then systemd is started from the root filesystem. Its cryptsetup 
generator processes the /etc/crypttab entries. It also processes the 
root entry, with its keyscript parameter, and generates under /run a 
service unit for it. Then systemd tries opening and mounting the LUKS 
device that is already opened and mounted, and get stuck until it times 
out. Then the boot proceeds successfully.


It seems to me that systemd has the assumption that an encrypted 
root device is NOT described in /etc/crypttab. I may be wrong on this 
but when I look at documentation from Arch, which has migrated to 
systemd, the encrypted root is handled through kernel parameters handled 
in the initramfs and not through /etc/cryptab. See for example:

https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#Boot_loader

This issue can be worked-arounded by using the (different from 
Arch) kernel parameters cryptopts in Debian too, and removing the root 
entry from /etc/crypttab. This is documented in README.initramfs.gz 
section 7, but the doc actually recommends against this and says it's 
better to use crypttab instead.


Another work-around would be for the generated systemd 
configuration to be robust against an already opened/mounted device, in 
case the system or user does things in the initramfs already. Or to 
ignore the root fs in /etc/crypttab, as on principle it is already there 
when systemd is started from it.
As a user I personally prefer having all my crypto partitions in 
one place under /etc/crypttab, rather than having to special case the 
root fs using kernel parameters. The root fs is a special case 
technically, but I'd rather have the infrastructure deal with this. I'm 
sure there will be othe opinions, in the end it's not a big deal as long 
as what's required is documented consistently across packages and 
existing configurations are migrated properly (if need be).


In any case, the initial bug does not apply to me: the keyscript 
parameter is for the initramfs and cryptsetup, and they handle it just 
fine. If Mourad still follows the thread, could you try on a recent 
Jessie or Sid release? (the initial bug is old now). The fix could be 
just a documentation alignment, and/or having systemd ignoring the root 
fs entry in crypttab.


All this under Jessie, with:
- systemd 208-6
- initramfs-tools 0.115
- cryptsetup 2:1.6.4-4

And by the way, thanks to all for the good work. The transition to 
systemd is rather smooth considering how big a change it is, and I like 
the result so far.


Thanks!


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[Evgeni Golov]

Version: 208-6

On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
 my root and swap partition are encrypted with cryptsetup; root uses a custom
 keyscript and swap uses the cryptsetup-provided decrypt_derived keyscript.
 systemd seems to be unable to work with keyscripts at all, and requires
 password input for every volume that wasn't activated already. Luckily, my
 root FS is activated by the initramfs.

I have a slightly simplier setup: small /boot, big crypted partition, 
with LVM on it. root and swap are LVs. The only interesting part is 
the `passdev` keyscript from pkg:cryptsetup, which mounts a device and 
reads a file on that device as the actual key.

With the upgrade from 204-14 to 208-6, my system shows an interesting 
behaviour. The crypt is properly opened in initrd, but then systemd 
decides to reopen it, totally failing to use the keyscript and its 
weird keyfile naming, resulting in a timeout:

Jul 18 20:42:29 nana systemd[1]: Expecting device 
dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device...
Jul 18 20:43:59 nana systemd[1]: Job 
dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device/start timed out.
Jul 18 20:43:59 nana systemd[1]: Timed out waiting for device 
dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device.
Jul 18 20:43:59 nana systemd[1]: Dependency failed for Cryptography Setup for 
nana-crypt.
Jul 18 20:43:59 nana systemd[1]: Dependency failed for Encrypted Volumes.

My crypttab:
# target name source device key file  options
nana-crypt  UUID=   
/dev/disk/by-label/usbext3:/keyfile-nana.luks:10 
luks,discard,keyscript=/lib/cryptsetup/scripts/passdev,tries=1

My fstab:
LABEL=nana-boot /boot   ext4noatime,discard 
0   0
/dev/mapper/nana--vg01-nana--root   /   ext4
noatime,discard,errors=remount-ro   0   1
/dev/mapper/nana--vg01-nana--home   /home   ext4
noatime,discard,errors=remount-ro   0   1
/dev/mapper/nana--vg01-nana--swap   noneswapdefaults
0   0

Greets
Evgeni


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[Marc Haber]

severity #618862 important
thanks

On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
 my root and swap partition are encrypted with cryptsetup; root uses a custom
 keyscript and swap uses the cryptsetup-provided decrypt_derived keyscript.
 systemd seems to be unable to work with keyscripts at all, and requires
 password input for every volume that wasn't activated already. Luckily, my
 root FS is activated by the initramfs.
 
 I don't want to have to type in a password for every encrypted volume: on
 some of my machines this would mean having to type five or more passwords on
 boot.

I have a quite similar setup, only that the keys needed to unlock the
12 LVs are like 300 bytes of binary gibberish long. Typing them during
system boot is kind of out of the question.

Missing keyscript support is a total surprise to me, which breaks my
three most important systems. I am thus raising the severity of this
bug to important. It could also be higher, since it breaks the system.

I am also concerned since I remember well analyzing the scripts in the
initrd when I developed my cryptdisk setup. Since these mechanics seem
to have moved into systemd, I have learned that I would not have been
able to find out what's going on during system boot if we had systemd
back then. I don't like that idea at all.

Management Summary: Please make keyscript work.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[Lennart Poettering]

On Sat, 08.02.14 21:07, David Härdeman (da...@hardeman.nu) wrote:

 
 On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
 On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
  This issue is fixable with minor upstream changes, e.g. by extending
  the PasswordAgent protocol to add Subsystem=cryptsetup and
  Target=diskname entries to the ask. file.
 
 I'd be fine with adding a field Id= or so, which then is filled by an
 identifier of some kind be the cryptsetup tool that is useful to
 identify the device to query things on. for example:
 Id=cryptsetup:/dev/sda5 or so could be one way how this could be
 filled in. We wouldn't enfoce any kind of syntax on this, just suggest
 some common sense so that people choose identifiers that are unlikely to
 clash with other subsystems, and somewhat reasonable to read...
 
 In the patches I sent I split it into Purpose and Target and my
 thinking was more or less the same as yours...i.e. that there's no
 particular syntax and that the meaning of the string is subsystem
 specific.
 
 I'd be happy to change the patch to use Id=subsystem:target if
 you'd prefer.

Yes, please!

  b) the password agent implementation in systemd doesn't seem to
  handle binary strings (i.e. strings with '\0'), as can be seen by
  calls to e.g. strlen()...
  
  Whether making it binary safe would be a major change or not is
  something I haven't researched yet but it seems like a change that
  should be generally useful upstream...
 
 I'd be OK with this, as discussed at FOSDEM, and I see you already
 posted a ptach for this.
 
 Yes. I take it you're pretty busy with the kdbus stuff right now but a
 review of those patches would be nice when you have the time.
 


Lennart

-- 
Lennart Poettering, Red Hat


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[David Härdeman]

On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
 This issue is fixable with minor upstream changes, e.g. by extending
 the PasswordAgent protocol to add Subsystem=cryptsetup and
 Target=diskname entries to the ask. file.

I'd be fine with adding a field Id= or so, which then is filled by an
identifier of some kind be the cryptsetup tool that is useful to
identify the device to query things on. for example:
Id=cryptsetup:/dev/sda5 or so could be one way how this could be
filled in. We wouldn't enfoce any kind of syntax on this, just suggest
some common sense so that people choose identifiers that are unlikely to
clash with other subsystems, and somewhat reasonable to read...

In the patches I sent I split it into Purpose and Target and my
thinking was more or less the same as yours...i.e. that there's no
particular syntax and that the meaning of the string is subsystem
specific.

I'd be happy to change the patch to use Id=subsystem:target if
you'd prefer.

 b) the password agent implementation in systemd doesn't seem to
 handle binary strings (i.e. strings with '\0'), as can be seen by
 calls to e.g. strlen()...
 
 Whether making it binary safe would be a major change or not is
 something I haven't researched yet but it seems like a change that
 should be generally useful upstream...

I'd be OK with this, as discussed at FOSDEM, and I see you already
posted a ptach for this.

Yes. I take it you're pretty busy with the kdbus stuff right now but a
review of those patches would be nice when you have the time.

-- 
David Härdeman


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[Tollef Fog Heen]

]] Lennart Poettering 

  a) the cryptsetup package
  
  b) as part of the Debian systemd package
  
  c) upstream systemd
 
 I'd prefer to keep this tool in a Debian-specific package. I am not
 convinced that the key script thing is something we should standardize
 on cross-distributions.

I think it makes sense to push upstream, but as long as it's reasonably
self-contained I don't mind having it in Debian, either in the systemd
package or (if the cryptsetup maintainer wants it) in cryptsetup.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[Lennart Poettering]

On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:

 a) getting the name of the cryptdev that the password request
 corresponds to currently involves parsing the prompt message
 (Please enter passphrase for disk %s!) which is obviously not a
 real solution...
 
 This issue is fixable with minor upstream changes, e.g. by extending
 the PasswordAgent protocol to add Subsystem=cryptsetup and
 Target=diskname entries to the ask. file.

I'd be fine with adding a field Id= or so, which then is filled by an
identifier of some kind be the cryptsetup tool that is useful to
identify the device to query things on. for example:
Id=cryptsetup:/dev/sda5 or so could be one way how this could be
filled in. We wouldn't enfoce any kind of syntax on this, just suggest
some common sense so that people choose identifiers that are unlikely to
clash with other subsystems, and somewhat reasonable to read...

 b) the password agent implementation in systemd doesn't seem to
 handle binary strings (i.e. strings with '\0'), as can be seen by
 calls to e.g. strlen()...
 
 Whether making it binary safe would be a major change or not is
 something I haven't researched yet but it seems like a change that
 should be generally useful upstream...

I'd be OK with this, as discussed at FOSDEM, and I see you already
posted a ptach for this.

 a) the cryptsetup package
 
 b) as part of the Debian systemd package
 
 c) upstream systemd

I'd prefer to keep this tool in a Debian-specific package. I am not
convinced that the key script thing is something we should standardize
on cross-distributions.

Lennart

-- 
Lennart Poettering, Red Hat


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[David Härdeman]

On 2013-06-25 17:47, Michael Biebl wrote:

Am 25.06.2013 13:13, schrieb Harald Jenny:

Dear Michael Biebl,

following the systemd survey and discussion I think these mails might 
be

of interest to you concerning possible ways to solve the current issue
(not only in Debian but also SuSE/upstream interest).

http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835


I personally don't own such hardware, and I never have userd
cryptsetup's keyscript support. So I'm probably not the most qualified
to evaluate the situation.
That said, reading the upstream discussion, I guess we have 3 options
a/ do nothing about it
b/ apply the patch from David Härdeman downstream and maintaining it as
a downstream patch forever
c/ try to implement keyscript support based on the PasswordAgent 
interface


a/ is obviously not very compelling. As for b/, we try to avoid
downstream patches as much as possible.
Regarding c/, I dunno how much effort that would be.

Bringing David into the loop here. Maybe he has some further insight on
this matter.


I found some time to consider how to solve this and I think I have a 
pretty good solution that'd require a minimum amount of changes 
upstream.


What I've hacked together is:

First, a patch to the askpass binary in cryptsetup (the Debian 
package, not systemd's own stuff) so that it'll detect that systemd is 
running, in which case it'll use systemd's own password agent system for 
requesting a password from the user.


Second, a new systemd password agent. It waits for a password request 
from systemd's own cryptsetup implementation. The password agent then 
re-parses /etc/crypttab to find the corresponding entry and checks if it 
includes a keyscript= option. If no keyscript option is present the 
agent does nothing but if it *is* present, the agent recreates the 
environment created by the current cryptsetup scripts, launches the 
keyscript and sends the output back via the appropriate socket provided 
by systemd.


That the changes to askpass and the introduction of the new password 
agent are unrelated but both are necessary to not break existing 
keyscripts. askpass is used in keyscripts to get an actual key from 
the user. The password agent makes sure that systemd's own cryptsetup 
stuff honors the keyscript.


The new agent is not production ready yet (I plan to do some more work 
on it during FOSDEM), the two most important issues are:


a) getting the name of the cryptdev that the password request 
corresponds to currently involves parsing the prompt message (Please 
enter passphrase for disk %s!) which is obviously not a real 
solution...


This issue is fixable with minor upstream changes, e.g. by extending the 
PasswordAgent protocol to add Subsystem=cryptsetup and 
Target=diskname entries to the ask. file.


b) the password agent implementation in systemd doesn't seem to handle 
binary strings (i.e. strings with '\0'), as can be seen by calls to e.g. 
strlen()...


Whether making it binary safe would be a major change or not is 
something I haven't researched yet but it seems like a change that 
should be generally useful upstream...




Minor detail: the additional agent could be shipped either in (I have no 
real preference):


a) the cryptsetup package

b) as part of the Debian systemd package

c) upstream systemd


Feedback welcome.

Regards,
David

[1] http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[Christoph Anton Mitterer]

Oh and I forget (but it seems this is already clear as well):

keyscripts may make use of arbitrary other programs... OpenSSL, pcscd,
gpg, etc. pp.
I've just attached my own keyscript to give an example (just the script,
not the initramfs-tools hook or documentation).

The biggest problem is likely stuff that requires terminal input (AFAIU
systemd takes this over or at least should do so).
In Debians cryptsetup, there's /lib/cryptsetup/askpass which I for
example use to gather the passphrase (which is used to decrypt the
OpenPGP encrypted actual key).

So I guess that needs to be adapted somehow as well... either this, or
properly documented how to do things in the systemd-way.
And of course, any keyscripts would then need to support both,... a
systemd-way of interactive input (if there is any)... and the
traditional via e.g. askpass (AFAIU, the tech-ctte decision will just
define a new default init,... but not forbid any others).


Cheers,
Chris.


decrypt_openpgp
Description: application/shellscript


smime.p7s
Description: S/MIME cryptographic signature

Bug#618862: systemd: ignores keyscript in crypttab

[Christoph Anton Mitterer]

Hi.

Had a private conversation with Tollef and he pointed me to this bug...

Even though it may be obvious to any developer, let me add the
following:
I had a short glance at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n54
I guess another crypt_activate_by_? function would need to be
implemented for keyscripts.

One thing which need to be taken into account is the following:

The keyscript is an arbitrary program (no necessarily a shell script...
and the key file parameter (the 3rd field in crypttab(5)) may _not_ be a
pathname at all.
I for example use a keyscript for openpgp encrypted keys (a different
one from that shipped in Debian, which has several functionality
deficiencies and following from that: security issues) where one would
see lines as the following in crypttab:

root   /dev/disk/by-uuid/74b4564a-728e-11e3-8a8d-502690aa641f   
device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root
   loud,luks,keyscript=decrypt_openpgp,tries=0

All of this is normal unless the 3rd field:
device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root
which is given to my keyscript decrypt_openpgp

It basically combines two options (separated by a colon) into the one
passed to the keyscript (which splits it again)...
device= being a filesystem which the keyscript should wait to appear
(i.e. a USB stick)... mount it ... and
pathname= being a a file local to the filesystem on that device... which
is then read, fed through gpg and so on.

And this is just one example where one could need multiple options put
together in the keyfile field of crypttab - unfortunately the Debian
maintainer refused to standardise this.

Another example could be a OpenPGP crypto smart card, where one waits
for a specific smart card ID to appear, and reads key number n from it.
Or one can think of examples where the key is read via secured network
connections (ssh, ipsec, whatever) and where multiple parameters would
be required.


So the point is... any support for keyscripts in systemd MUST NOT try to
be smarter than it should and somehow interpreting or modifying the
keyfile field.
It simply MUST pass that on the the keyscript, just as the Debian
cryptsetup scripts do it.

And it should be noted, that the cryptsetup scripts initialise a bunch
of environment variables for the executed keyscript program, which of
course systemd would need to do as well.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#618862: [Pkg-systemd-maintainers] Bug#618862: systemd: ignores keyscript in crypttab - possibilities to solve this issue

[David Härdeman]

On Tue, Jun 25, 2013 at 05:47:19PM +0200, Michael Biebl wrote:
Am 25.06.2013 13:13, schrieb Harald Jenny:
 Dear Michael Biebl,
 
 following the systemd survey and discussion I think these mails might be
 of interest to you concerning possible ways to solve the current issue
 (not only in Debian but also SuSE/upstream interest).
 
 http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
 http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835

I personally don't own such hardware, and I never have userd
cryptsetup's keyscript support. So I'm probably not the most qualified
to evaluate the situation.

You don't actually need any hardware though. A keyscript (for a testing
environment) could simply echo a fixed password and be used to decrypt a
loopback device.

That said, reading the upstream discussion, I guess we have 3 options
a/ do nothing about it
b/ apply the patch from David Härdeman downstream and maintaining it as
a downstream patch forever
c/ try to implement keyscript support based on the PasswordAgent interface

a/ is obviously not very compelling. As for b/, we try to avoid
downstream patches as much as possible.
Regarding c/, I dunno how much effort that would be.

Bringing David into the loop here. Maybe he has some further insight on
this matter.

I still think it's too early to rule out option c). Contrary to what
some other people seem to think, I don't find Lennart difficult to work
with (not more so than any other average upstream).

It would probably be a lot of work though since a good solution would
probably need further additions to the PasswordAgent API (to name but
one problem, imagine a keyscript that would in turn fetch a key from a
smartcard and which needed to get the PIN from the user...it would in
effect require two calls through the PasswordAgent stack but only one
prompt - the one for the PIN - should be displayed to the user).

I don't believe that I will have the time to implement and drive a
change of that scope in the foreseeable future...

-- 
David Härdeman


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab - possibilities to solve this issue

[Harald Jenny]

Dear Michael Biebl,

following the systemd survey and discussion I think these mails might be
of interest to you concerning possible ways to solve the current issue
(not only in Debian but also SuSE/upstream interest).

http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835

Kind regards
Harald Jenny


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: [Pkg-systemd-maintainers] Bug#618862: systemd: ignores keyscript in crypttab - possibilities to solve this issue

[Michael Biebl]

Am 25.06.2013 13:13, schrieb Harald Jenny:
 Dear Michael Biebl,
 
 following the systemd survey and discussion I think these mails might be
 of interest to you concerning possible ways to solve the current issue
 (not only in Debian but also SuSE/upstream interest).
 
 http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
 http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835

I personally don't own such hardware, and I never have userd
cryptsetup's keyscript support. So I'm probably not the most qualified
to evaluate the situation.
That said, reading the upstream discussion, I guess we have 3 options
a/ do nothing about it
b/ apply the patch from David Härdeman downstream and maintaining it as
a downstream patch forever
c/ try to implement keyscript support based on the PasswordAgent interface

a/ is obviously not very compelling. As for b/, we try to avoid
downstream patches as much as possible.
Regarding c/, I dunno how much effort that would be.

Bringing David into the loop here. Maybe he has some further insight on
this matter.

Tollef, what's your take on this?


cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#618862: systemd: ignores keyscript in crypttab

[Michael Biebl]

http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n45

/* Options Debian's crypttab knows we don't:

offset=
skip=
precheck=
check=
checkargs=
noearly=
loud=
keyscript=
*/
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#618862: systemd: ignores keyscript in crypttab

[Mourad De Clerck]

Package: systemd
Version: 19-1
Severity: normal

Hi,

my root and swap partition are encrypted with cryptsetup; root uses a custom
keyscript and swap uses the cryptsetup-provided decrypt_derived keyscript.
systemd seems to be unable to work with keyscripts at all, and requires
password input for every volume that wasn't activated already. Luckily, my
root FS is activated by the initramfs.

I don't want to have to type in a password for every encrypted volume: on
some of my machines this would mean having to type five or more passwords on
boot.

Is there any way of using keyscripts or some equivalent with systemd?


FYI, some (abbreviated) info on my machine.


/etc/fstab:

/dev/mapper/root  / ext3  relatime,user_xattr,errors=remount-ro 0   1
/dev/sda1 /boot ext3  noatime   0   2
/dev/mapper/swap  none  swap  sw0   0


/etc/crypttab:

rootUUID=...  /dev/...  
luks,keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev
swapUUID=...  root  
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived


/var/log/syslog:

systemd-initctl[10973]: Received environment initctl request. This is not 
implemented in systemd.
systemd-fsck[452]: root: clean, 444366/13107200 files, 47184313/52427870 blocks
systemd-cryptsetup[735]: Encountered unknown /etc/crypttab option 
'keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev', ignoring.
systemd-cryptsetup[735]: Volume root already active.
systemd-cryptsetup[781]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[781]: Encountered unknown /etc/crypttab option 
'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-fsck[738]: /dev/sda1: clean, 255/65952 files, 57208/263056 blocks
systemd-cryptsetup[781]: Invalid packet
systemd-cryptsetup[781]: Timed out
systemd-cryptsetup[781]: Failed to query password: Timer expired
systemd-cryptsetup[1102]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[1102]: Encountered unknown /etc/crypttab option 
'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-cryptsetup[1102]: Timed out
systemd-cryptsetup[1102]: Failed to query password: Timer expired
systemd-cryptsetup[1399]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[1399]: Encountered unknown /etc/crypttab option 
'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-cryptsetup[1399]: Timed out
systemd-cryptsetup[1399]: Failed to query password: Timer expired



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  libaudit01.7.13-1+b2 Dynamic library for security audit
ii  libc62.11.2-13   Embedded GNU C Library: Shared lib
ii  libcap2  1:2.20-1support for getting/setting POSIX.
ii  libcryptsetup1   2:1.2.0-2   libcryptsetup shared library
ii  libdbus-1-3  1.4.6-1 simple interprocess messaging syst
ii  libpam0g 1.1.2-2 Pluggable Authentication Modules l
ii  libselinux1  2.0.96-1SELinux runtime shared libraries
ii  libudev0 166-1   libudev shared library
ii  util-linux   2.17.2-9.1  Miscellaneous system utilities

Versions of packages systemd recommends:
ii  libpam-systemd19-1   system and service manager - PAM m

Versions of packages systemd suggests:
ii  systemd-gui   19-1   system and service manager - GUI

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org