4 ms·

I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is

by csirac2 12y ago

I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is actually a good idea and happened to work well when I played with it. But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypttab. Apparently the answer is to write a different custom C program for every possible permutation of obtaining key material to feed to cryptsetup: http://lists.freedesktop.org/archives/systemd-devel/2014-August/022024.html http://lists.freedesktop.org/archives/systemd-devel/2014-Aug... ... which is somehow more clean than a 4 line keyscript. ... and certainly lends credence to the idea that systemd just isn't unixy.

cbsmith 12y ago
Using shell scripts to do decryption seems dicey at best...
- csirac2 12y ago
  It's dicey to obtain key material from external hardware because...?
  - cbsmith 12y ago
    Shell scrips have issues with race conditions (which is why they aren't setuid) and just generally create a lot of points of exposure.
    - simoncion 12y ago
      What? Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language. As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay: /usr/lib/kde4/libexec/fileshareset: setuid Perl script, ASCII text executable
      - cbsmith 12y ago
        Perl goes to great lengths to be secure in the face of setuid. This isn't even remotely controversial. There is a reason that the setuid bit is ignored for unix shell scripts.
- csirac2 12y ago
  During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?
  - XorNot 12y ago
    Conversely a well-coded C program isn't pulling in a huge amount of additional, irrelevant functionality to the task.
    - csirac2 12y ago
      Yet it seems installing systemd drags dbus and bunch of other dependencies in with it... tomato, potato.
      - cbsmith 12y ago
        dbus was already there. How do you think udev works?
        EmanueleAina 12y ago
        To be fair, udev communicates over netlink. :) Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces. On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).
        cbsmith 12y ago
        > To be fair, udev communicates over netlink. :) To be fair, udev communicates with the kernel via netlink. All the userspace notifications are done via dbus. So dbus was already part of the equation whether people realize it or not. http://blogas.sysadmin.lt/?p=141 http://blogas.sysadmin.lt/?p=141
yaantc 12y ago
You can still use a keyscript (I do), it just need to be done in a different way. Instead of putting the configuration in /etc/crypttab, which confuses systemd indeed, you can still use the kernel cryptopts variable. For example, in the grub configuration add something like: cryptopts=source=/dev/<disk>,target=sdc5_crypt,keyscript=/lib/cryptsetup/scripts/passdev,key=/dev/<other_disk>:/somdir/root.key Anf then in /etc/fstab use the /dev/mapper/<target> (sdc5_crypt in the example above) as the root device, as before. Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it. I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.
- csirac2 12y ago
  Thanks, I appreciate the hint, I should have noticed that a kernel parameter would be one way to do it (I'm familiar with writing initramfs-tools/hooks to make the existing keyscripts work). The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)
  - mercurial 12y ago
    That's obviously a problem but more a migration script problem than a systemd problem, I'd say.

by csirac2 12y ago

cbsmith 12y ago

Using shell scripts to do decryption seems dicey at best...

csirac2 12y ago
It's dicey to obtain key material from external hardware because...?
- cbsmith 12y ago
  Shell scrips have issues with race conditions (which is why they aren't setuid) and just generally create a lot of points of exposure.
  - simoncion 12y ago
    What? Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language. As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay: /usr/lib/kde4/libexec/fileshareset: setuid Perl script, ASCII text executable
    - cbsmith 12y ago
      Perl goes to great lengths to be secure in the face of setuid. This isn't even remotely controversial. There is a reason that the setuid bit is ignored for unix shell scripts.
csirac2 12y ago
During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?
- XorNot 12y ago
  Conversely a well-coded C program isn't pulling in a huge amount of additional, irrelevant functionality to the task.
  - csirac2 12y ago
    Yet it seems installing systemd drags dbus and bunch of other dependencies in with it... tomato, potato.
    - cbsmith 12y ago
      dbus was already there. How do you think udev works?
      - EmanueleAina 12y ago
        To be fair, udev communicates over netlink. :) Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces. On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).
        cbsmith 12y ago
        > To be fair, udev communicates over netlink. :) To be fair, udev communicates with the kernel via netlink. All the userspace notifications are done via dbus. So dbus was already part of the equation whether people realize it or not. http://blogas.sysadmin.lt/?p=141 http://blogas.sysadmin.lt/?p=141

yaantc 12y ago

You can still use a keyscript (I do), it just need to be done in a different way. Instead of putting the configuration in /etc/crypttab, which confuses systemd indeed, you can still use the kernel cryptopts variable. For example, in the grub configuration add something like: cryptopts=source=/dev/<disk>,target=sdc5_crypt,keyscript=/lib/cryptsetup/scripts/passdev,key=/dev/<other_disk>:/somdir/root.key Anf then in /etc/fstab use the /dev/mapper/<target> (sdc5_crypt in the example above) as the root device, as before. Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it. I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.

csirac2 12y ago
Thanks, I appreciate the hint, I should have noticed that a kernel parameter would be one way to do it (I'm familiar with writing initramfs-tools/hooks to make the existing keyscripts work). The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)
- mercurial 12y ago
  That's obviously a problem but more a migration script problem than a systemd problem, I'd say.