4 ms·

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

by 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
        EmanueleAina 12y ago
        Are you sure? IIRC it was HAL that picked the kernel events and converted to D-Bus signals, but it has been deprecated a long time ago. I gave a cursory glance to the systemd/src/udev files and found no mention of dbus.
    - csirac2 12y ago
      I build debian chroots with sysv init. Edit: they have libdbus, but aren't running the dbus daemon, but are running udevd.
cbsmith 12y ago
You raise a good point. I hadn't considered a shell based init system where the shell scripts only run at startup and aren't available to run at any other time. You mentioned smart cards... what system would handle when you connect a smart card after boot?
- csirac2 12y ago
  The trigger is the appearance of the volume. If the mounter actions crypttab properly it'll run the keyscript which challenges the smartcard or TPM or USB crypt token or some combination thereof, which in turn provides the response to cryptsetup. By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.
  - cbsmith 12y ago
    > The trigger is the appearance of the volume. I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc. Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens). Now handle the case where you have a bad connection so it is constantly flapping as inserted & not. Now handle the case where it gets ripped out with no warning. Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
    - csirac2 12y ago
      I think I get your point, but for what it's worth the sysvinit cryptroot/crypttab setup has worked seamlessly for servers for years. Basically if keyscript fails (smart card not available or challenge material not available or TPM won't unseal) it falls back to ask pass on a TTY with the hopes that you can type something in. I also do appreciate the systemd features for mobile and desktop devices. But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv). Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years

by csirac2 12y ago

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
      - EmanueleAina 12y ago
        Are you sure? IIRC it was HAL that picked the kernel events and converted to D-Bus signals, but it has been deprecated a long time ago. I gave a cursory glance to the systemd/src/udev files and found no mention of dbus.
  - csirac2 12y ago
    I build debian chroots with sysv init. Edit: they have libdbus, but aren't running the dbus daemon, but are running udevd.

cbsmith 12y ago

You raise a good point. I hadn't considered a shell based init system where the shell scripts only run at startup and aren't available to run at any other time. You mentioned smart cards... what system would handle when you connect a smart card after boot?

csirac2 12y ago
The trigger is the appearance of the volume. If the mounter actions crypttab properly it'll run the keyscript which challenges the smartcard or TPM or USB crypt token or some combination thereof, which in turn provides the response to cryptsetup. By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.
- cbsmith 12y ago
  > The trigger is the appearance of the volume. I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc. Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens). Now handle the case where you have a bad connection so it is constantly flapping as inserted & not. Now handle the case where it gets ripped out with no warning. Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
  - csirac2 12y ago
    I think I get your point, but for what it's worth the sysvinit cryptroot/crypttab setup has worked seamlessly for servers for years. Basically if keyscript fails (smart card not available or challenge material not available or TPM won't unseal) it falls back to ask pass on a TTY with the hopes that you can type something in. I also do appreciate the systemd features for mobile and desktop devices. But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv). Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years