In the second part of his blog post, Strauss argues that systemd improves security
by making it easy to apply hardening techniques to the network services
which he calls the "keepers of data attackers want." According to Strauss,
I'm "fighting one of the most powerful tools
we have to harden the front lines against the real attacks we see every
day." Although systemd does make it easy to restrict the privileges
of services, Strauss vastly overstates the value of these features.

The best systemd can offer is whole application sandboxing.
You can start a daemon as a non-root user, in a restricted
filesystem namespace, with mandatory access control.
Sandboxing an entire application is an effective way to
run potentially malicious code, since it protects other applications
from the malicious one. This makes sandboxing useful on smartphones,
which need to run many different untrustworthy, single-user applications.
However, since sandboxing a whole application cannot protect one part of the
application from a compromise of a different part, it is ineffective at
securing benign-but-insecure software, which is the problem faced
on servers. Server applications need to service requests from many different users.
If one user is malicious and exploits a vulnerability in the application,
whole application sandboxing doesn't protect the other users of the service.

For concrete examples, let's consider Apache and Samba, two daemons
which Strauss says would benefit from systemd's features.

First Apache. You can start Apache as a non-root user provided someone
else binds to ports 443 and 80. You can further sandbox it
by preventing it from accessing parts of the filesystem it doesn't need to access.
However, no matter how much you try to sandbox Apache, a typical setup is
going to need a broad amount of access to do its job, including read permission
to your entire website (including password-protected parts) and access to
any credential (database password, API key, etc.) used by your CGI, PHP,
or similar webapps.

Even under systemd's most restrictive sandboxing, an attacker who
gains remote code execution in Apache would be able to read your
entire website, alter responses to your visitors, steal your HTTPS
private keys, and gain access to your database and any API consumed
by your webapps. For most people, this would be the worst possible compromise,
and systemd can do nothing to stop it. Systemd's sandboxing would prevent
the attacker from gaining access to the rest of your system (absent a vulnerability
in the kernel or systemd), but in today's world of single-purpose VMs and containers,
that protection is increasingly irrelevant. The attacker probably only wants your database anyways.

To provide a meaningful improvement to security without rewriting in a memory-safe language, Apache would need to implement
proper privilege separation. Privilege separation means using multiple processes internally, each running
with different privileges and responsible for different tasks, so that a compromise while performing
one task can't lead to the compromise of the rest of the application.
For instance, the process that accepts HTTP connections could
pass the request to a sandboxed process for parsing, and then pass the parsed
request along to yet another process which is responsible for serving
files and executing webapps. Privilege separation has been used effectively
by OpenSSH, Postfix, qmail, Dovecot, and over
a dozen daemons in OpenBSD.
(Plus a couple of my own: titus
and rdiscd.)
However, privilege separation requires
careful design to determine where to draw the privilege boundaries and how to interface between them.
It's not something which an external tool such as systemd can provide.
(Note: Apache already implements privilege separation that
allows it to process requests as a non-root user, but it is too
coarse-grained to stop the attacks described here.)

Next Samba, which is a curious choice of example by Strauss. Having configured Samba
and professionally administered Windows networks, I know that Samba cannot
run without full root privilege. The reason why Samba needs privilege is not
because it binds to privileged ports, but because, as a file server, it needs the
ability to assume the identity of any user so it can read and write that user's files.
One could imagine a different design of Samba in which all files are owned by the same unprivileged
user, and Samba maintains a database to track the real ownership of each file. This
would allow Samba to run without privilege, but it wouldn't necessarily be more secure
than the current design, since it would mean that a post-authentication vulnerability would yield
access to everyone's files, not just those of the authenticated user. (Note: I'm not sure if Samba is
able to contain a post-authentication vulnerability, but it theoretically could. It absolutely
could not if it ran as a single user under systemd's sandboxing.)

Other daemons are similar. A mail server needs access to all users' mailboxes. If the mail server is written in C,
and doesn't use privilege separation, sandboxing it with systemd won't
stop an attacker with remote code execution from reading every user's
mailbox. I could continue with other daemons, but I think I've made my point: systemd is
not magic pixie dust that can be sprinkled on insecure server applications to make them secure.
For protecting the "data attackers want," systemd is far from a "powerful"
tool. I wouldn't be opposed to using a library or standalone tool to sandbox daemons as a last line of defense, but the amount of security it provides is not worth the
baggage of running systemd as PID 1.

Achieving meaningful improvement in software security won't be as easy as adding a few lines
to a systemd config file. It will require new approaches, new tools, new languages.
Jon Evans sums
it up eloquently:

... as an industry, let's at least set a trajectory. Let's move towards writing system code in better languages, first of all -- this should improve security and speed. Let's move towards formal specifications and verification of mission-critical code.

Systemd is not part of this trajectory. Systemd is more of the same old, same old, but with vastly more code and complexity,
an illusion of security features, and, most troubling, lock-in. (Strauss dismisses my lock-in concerns by dishonestly
claiming that applications aren't encouraged to use their non-standard DBUS API for DNS resolution.
Systemd's own
documentation says "Usage of this API is generally recommended to clients." And while systemd doesn't
preclude alternative implementations, systemd's specifications are not developed through a vendor-neutral process
like the IETF, so there is no guarantee that other implementers would have an equal seat at the table.)
I have faith that the Linux ecosystem can correct its trajectory. Let's start now, and stop following
systemd down the primrose path.