Bug#727708: systemd (security) bugs (was: init system question)
Ian Jackson wrote:
> It isn't always 100% clear to me from reading these which of them
> apply to systemd's init replacement. But reading the systemd debate
> page makes it clear that the other components in the systemd upstream
> package are seen by systemd proponents as part of their offering, and
> indeed reasons to pick systemd.
Yes, the other tools that systemd provides and enables are part of its
usefulness, so it is appropriate to look into their quality.
> I should say that it is hard to write code with no security bugs at
> all. But I think our benchmark for security bugs in our init system
> ought to be "very few", particularly if we are making a specific
> implementation effectively mandatory. And I don't think I would like
> to accept justifications (for a large bug count) along the lines of
> "but systemd does so much more"; I think the security bugs that come
> with a large codebase, or having more functionality exposed to
> ordinary users, are a direct and very relevant downside to such a
> large codebase or large attack surface.
But this, I think, is completely wrong. You shouldn't count bugs from
other tools included with systemd against its core init functionality or
vice versa. If for example systemd and coreutils came from the same
source package, that should be "allowed" as many bugs as the current two
separate source packages, not less.
Most of the separate functionality is optional. It's likely that Debian
would want to use it, but then Debian would want that functionality with
other init systems too (or miss it). The most appropriate comparison is
whether it's possible to have similar functionality with less bugs
(whether provided with init system or completely independently). As far
as I can see, for most functionality there are no such alternatives.
At least Upstart, and likely other alternatives to systemd also, would
still use forked versions of at least logind and possibly other tools
originating from systemd. Such forks are worse for security than using
the original systemd one. Thus the fact that logind is developed with
systemd should count in favor of systemd, not against it.
Also, systemd is the system under the most intense scrutiny for security
and other issues, so it's not easy to compare bug counts with
alternatives - alternatives likely have a significantly larger portion
of issues undetected.
> Here are a couple of exciting snippets:
> https://bugzilla.redhat.com/show_bug.cgi?id=708537
>
> Problems with runlevel emulation doing mad things. It isn't clear
> to me whether this bug is a symptom of a fundamental problem with
> systemd's state-based dependency model, or whether it's simply a
I think it's completely obvious that there is no "fundamental problem".
I wonder what could make you consider it a possible symptom of one.
> missing feature or perhaps even wrong default configuration. But
> the bug has been open for some time.
My guess is that most people do not consider that "exciting" or really
care - thinking of system states in terms of "runlevels" is mostly
obsolete, and the flaws do not bother many people in the cases where
backwards compatibility is still needed.
Reply to: