Hacker News Reader

Comment by geggo98 | Hacker News Reader

Actually you have a point. A collection of shell scripts (like the classical init systems) have obviously a smaller attack surface. In this case the attacker used some integration code with systemd to attack the ssh daemon. So sshd without systemd integration is safe against this specific attack.

In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd.

Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.

View on HN

It’s also tricky to reason about risk: for example, ShellShock caused a bunch of vulnerabilities in things which used shell scripts and the classic SysV Init system was a factor in a ton of vulnerabilities over the years because not having a standard way to do things like drop privileges or namespace things, manage processes, difficulties around managing chroot, etc. meant that you had a bunch of people implementing code which ran with elevated privileges because it needed to do things like bind to a low network port and they either had vulnerabilities in the privileged part or messed up some detail. I think in general it’s been much better in the systemd era where so much of that is builtin but I have been happy to see them starting to trim some of the things like the compression format bindings and I expect this will spur more.

I really appreciate your tone and dialectic reasoning, thanks for your reply. And yes, as simple as it sounds, I believe that shell scripts help a lot to maintain mission critical tools. One hands-on example is https://dyne.org/software/tomb where I took this approach to replace whole disk encryption which is nowadays also dependent on systemd-cryptsetup.

Is this an example of a simple and clean solution via shell script? I have some stylistic doubts:

1. What "exitcode" is set for:

  exitcode=1
  exit 1

2. I see a lot of "return $?". Why "$?" is returned if by default the shell returns the return value of the last command? Just ti name a few:

  lklfuse -o type=ext4 "${loop}" "$mnt"
  return $?
  ...
  veracrypt  --text --non-interactive -d "$file"
  return $?
  ...
  mount "$loop" "$mnt"
  return $?

3. Aren't =, != etc. used to compare strings and -eq, -ne, -gt etc. used to compare numbers? I see lot of numbers compared as strings, e.g.:

  [ $? = 0 ]
  [ $? != 0 ]
  [ $exitcode = 0 ]

4. There are lot of "cat <<EOF" blocks without indentation. I understand that this is made because the shell expects "EOF" on the line start, but there is a special syntax designed on purpose for this use case, simply put a dash between << and the token, e.g. "cat <<-EOF". In this case:

  tomb_init() {
   system="`uname -s`"
   case "$system" in
    FreeBSD)
     cat <<-EOF
     create=posix_create
     format=posix_format
     map=posix_map
     mount=freebsd_mount
     close=freebsd_close
     EOF
     ;;
    Linux)

5. Aren't backtick deprecated in favor of $()?

thanks for your review! tho you are referring to the tomb-portable unfinished experiment which is about to be dismissed since cross-platform experiments with veracrypt show very bad performance.

you are welcome to share a review of the tomb script, but be warned in that we use a lot of zsh specific features. It is a script that works since 15+ years so it has a discrete amount of patchwork to avoid regressions.

Reply on news.ycombinator.com