4 ms·

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

by cbsmith 12y ago

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
        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.

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

by 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
        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.