Hacker News Reader

Hacker News

Comment by tinus_hn | Hacker News Reader

Full thread

tinus_hn

Why does systemd have functionality to create files as root for unprivileged users anyway? What's the point?

View on HN

I don't like systemd, but for the benefit of the doubt. One of the dangerous lines of code is in a touch_file function:

https://github.com/systemd/systemd/blob/ee735086f8670be1591f...

..and most init systems do have a legitimate use case for touching a file.

If only UNIX provided an existing utility to do that...

So you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?

Well, I want PID 1 to make exactly one userland binary call and then start reaping orphans. I want that PID 2, the RC system, to read some configuration file(s) and, yeah, fork and exec a bunch of userland binaries. It's kind of the whole point, right?

What's the advantage of such an architecture?

The advantage is that the kernel panics if PID 1 ever crashes, so I want PID 1 never to crash or even be able to crash. It also means I want the binary to have as little of an attack surface as possible, and particularly I don't want it listening to dbus or having links to a QR generation library.

This is a solved problem with multiple good solutions [1] [2] [3], so I can easily avoid those issues by not using systemd.

[1] http://www.gnu.org.ua/software/pies/

[2] http://universe2.us/epoch.html

[3] http://core.suckless.org/sinit

So add a signal handler that just enters an endless loop. That's what systemd does, so as not to panic the kernel on a crash.

By the way, systemd doesn't listen to dbus (it uses the dbus protocol for IPC) and does not link to a QR generation library (journalctl does, which is your usual unprivileged program).

Great, now you have the issue of converting parameters to strings when invoking the binary. For example, the touched file's mode.

most init systems do have a legitimate use case for touching a file.

Can you name such a legitimate use case then? All I can think of is the need to write a pid file, and pid files are a kludge that real service supervisors gladly do away with.

systemd does not have such functionality. You have not read the headlined message correctly.

Rather, it has functionality to "touch" files in sensitive places, and a bug that meant that they were made world-writable, world-executable, and set-UID. The headlined message alludes to the various uses of this touch function that expose such files to the world to be exploited in certain circumstances, which (amongst others) are:

* timestamp files for timer units

* device tags files in systemd-udev

* /run/udev/queue

* timestamp files used by timesyncd

* private devices, bind mounts, and mirrored /etc/resolv.conf created by systemd-nspawn

* "linger" flags used by systemd-logind

* temporary files used by "systemctl edit"

* All sorts of flag files: /run/systemd/journal/flushed , /run/systemd/quotacheck , /run/systemd/show-status , /run/systemd/first-boot

Okay, so the problem arises due to:

* bad luck so a signedness issue doesn't cause a warning

* the use of the worst possible value as the invalid value

* no testing

* no defense in depth: no other component in the system appears to notice a file with such a dangerous mode set

Runtime directories, socket files, etc.

Reply on news.ycombinator.com