Bug#727708: systemd (security) bugs (was: init system question)

[Ian Jackson]

A friend of mine mentioned to me in the pub that he had seem alarming
reports of systemd security bugs. Naturally I asked for more
information and he promised me an email with some references.

So, here's what Andrew sent me. Thanks to Andrew for doing this
legwork.

I'll reply substantively in a moment.

[Ian Jackson]

but it actually only mentions three vulnerabilities, there's a more complete
list of the ones that have affected Debian at
https://security-tracker.debian.org/tracker/source-package/systemd

In summary, I agree with Andrew Kanaber's view that the security and
bug history of systemd is worrying.

Here's a short summary along with the redhat bug numbers (since the
redhat BTS seems to be the place to go for systemd information)
CVE summary Debian BTS Redhat
2012-0871 systemd-logind insecure file creation ? 795853
2012-1101 DoS from systemctl status 662029 799902
2012-1174 TOCTOU deletion race in systemd-logind 664364 803358
2013-4327 insecure use of polkit 723713 1006680
2013-4391 systemd journald integer overflow 725357 859051
2013-4392 TOCTOU race updating file perms 725357 859060
2013-4393 systemd journald DoS 725357 859104
2013-4394 improper sanitization of XKB layouts 725357 862324

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. Integration between the different
parts of the systemd package is touted as an advantage. For example,
journald is mentioned in the 2nd bullet point under Functionality. So
I think it it is sensible to look at security or other significant
bugs, even in those other systemd components.

Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
the systemd codebase when assessing the likely code quality of the pid
1 parts.

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.


I went and looked at the security bugs Andrew lists:

There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
which I think a concurrent init system author ought really to be
competent to avoid. (And the system should be designed, so far as
possible, to reduce the opportunity for such races.)

The "systemctl status" resource usage DoS (CVE-2012-1101) is an
understandable resource leak, given systemd's design. But for me it
raises this question: why is the system designed in such a way that
the critical pid 1 is required to implement functionality (and
unprivileged-facing interfaces) in which such a resource leak is (a) a
likely programming error and then (b) exposed so as to be exploitable.

AIUI the journald integer overflow (CVE-2013-4391) is a remotely
exploitable bug, if you have configured journald to allow remote
logging. (I assume this isn't the default configuration but haven't
checked.)

The other journald one (CVE-2013-4393) seems to stem from a poor
design decision: journald expects to be given an fd and then reads
from it. The authors of this obviously-security-critical code failed
to appreciate the variety of exciting things that can happen to the
recipient of an fd. I wonder even whether the code change
http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd
which is supposed to fix the bug is sufficient. Even if it does it
certainly isn't pretty. But also it is concerning that people who
have decided to make extensive use of advanced features of the Linux
system call interface apparently aren't aware of important and
hopefully well-known dangers in facilities such as cross-trust-domain
fd passing.

The XKB one (CVE-2013-4394) is concerning too. I can't quite tell
exactly in what configurations you would be vulnerable, but the bug
itself is not reassuring as regards the authors' additude to
cross-trust-boundary data processing. It looks like there's a bunch
of filenames which are taken from the untrusted side and just
textually stuffed into the X server configuration. Even after the
change which is supposed to fix it,
http://cgit.freedesktop.org/systemd/systemd/commit/?id=0b507b17a760b21e33fc52ff377db6aa5086c6800
it looks like the system might still accept editor backup,
auto-save files, and the like - the filename patterns which are
accepted seem far too generous. I wonder if the authors know whether
whether they are exposing the X server to malicious XKB data.

The bug I mentioned one where bad data in its binary log files causes journald
to go mad and eventially fill up /var with junk is
https://bugzilla.redhat.com/show_bug.cgi?id=974132
and is apparently still not fixed.

I read this and some of the links from it. This is indeed concerning.
Mostly my reaction is "why on earth is this all so complicated?"

Generally the RedHat BTS at
https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd
and
https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd+Status:CLOSED
make alarming reading

I agree with this sentiment. I just looked at a few of these.
Here are a couple of exciting snippets:

https://bugzilla.redhat.com/show_bug.cgi?id=693605#c1

systemd invents ENOEXEC, resulting in a genuine error due to cycles
in the dependency graph being reported as "Exec format error" (!)
In April 2011 a commenter suggests using EINVAL instead but the
bug unaccountably remains open.

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
missing feature or perhaps even wrong default configuration. But
the bug has been open for some time.


Ian.

[Michael Stapelberg]

Hi Ian,

Post by Ian Jackson

CVE summary Debian BTS Redhat
2012-0871 systemd-logind insecure file creation ? 795853
2012-1101 DoS from systemctl status 662029 799902
2012-1174 TOCTOU deletion race in systemd-logind 664364 803358
2013-4327 insecure use of polkit 723713 1006680
2013-4391 systemd journald integer overflow 725357 859051
2013-4392 TOCTOU race updating file perms 725357 859060
2013-4393 systemd journald DoS 725357 859104
2013-4394 improper sanitization of XKB layouts 725357 862324

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

2012-1101 does, I think 2013-4327 and 2013-4392 might, all the others do
not affect the init part of src:systemd.

Post by Ian Jackson
Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
the systemd codebase when assessing the likely code quality of the pid
1 parts.

I don’t really agree. The code quality of other parts of the systemd
ecosystem sure are related and probably provide a good trend of the
overall code quality. However, there are some “subsystems” of systemd,
which are to a big part written by non-core contributors. Take for
example networkd, a minimal network configuration for static
(server-ish) setups, which was largely implemented by Tom Gundersen:
http://cgit.freedesktop.org/systemd/systemd/log/src/network
Or take journald, which also has plenty of contributors:
http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=50
http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=100

One can compare this to the Linux kernel, I think: looking at any
subsystem will give you a somewhat useful idea about the overall code
quality, but it’s not fair to say linux’s syscall security sucks just
by looking at the filesystem code.

Post by Ian Jackson
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.

They sure are. OTOH, chosing the init system that receives the most
attention in form of development and is adopted by many other
distributions helps us a lot with security issues. They are no longer
just our problem, but other distributions also care about getting them
fixed quickly.

Post by Ian Jackson
There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
which I think a concurrent init system author ought really to be
competent to avoid. (And the system should be designed, so far as
possible, to reduce the opportunity for such races.)

“a concurrent init system author” sounds strange on multiple counts:
systemd was not written by one author. It is also not concurrent (in
fact it is single-threaded and only links to pthreads to call sync
asynchronously on shutdown), but event-based. As for competency, I am
sure that everybody involved has learned their lesson and will avoid
such issues in the future. I am also sure that other init systems have
(had) similar bugs. And if there is no evidence of that yet, maybe
nobody looked really closely yet…? :)

Post by Ian Jackson
The "systemctl status" resource usage DoS (CVE-2012-1101) is an
understandable resource leak, given systemd's design. But for me it
raises this question: why is the system designed in such a way that
the critical pid 1 is required to implement functionality (and
unprivileged-facing interfaces) in which such a resource leak is (a) a
likely programming error and then (b) exposed so as to be exploitable.

a) I think “a likely programming error” is an exaggeration. Do you have
data on how often there were resource leaks in systemd?
b) I am unclear on how exactly this was exploitable, and the bugs lack
explanation unfortunately.

Furthermore, I think Lennart’s explanation of why arbitrary units must
be able to be created is fair:
https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1

Post by Ian Jackson
AIUI the journald integer overflow (CVE-2013-4391) is a remotely
exploitable bug, if you have configured journald to allow remote
logging. (I assume this isn't the default configuration but haven't
checked.)

journald does not provide remote logging. See
https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html

Post by Ian Jackson
The other journald one (CVE-2013-4393) seems to stem from a poor
design decision: journald expects to be given an fd and then reads
from it. The authors of this obviously-security-critical code failed
to appreciate the variety of exciting things that can happen to the
recipient of an fd. I wonder even whether the code change
http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd
which is supposed to fix the bug is sufficient. Even if it does it
certainly isn't pretty. But also it is concerning that people who
have decided to make extensive use of advanced features of the Linux
system call interface apparently aren't aware of important and
hopefully well-known dangers in facilities such as cross-trust-domain
fd passing.

Personally, I don’t know about every little detail in fd passing
either. If I read you correctly, you seem to be saying one needs to be
an expert in a given area before being allowed to write code in it. I
think it works the other way around: by writing code in that area, you
become an expert in it.

The general statement from your side here seems to be (exaggerating a
bit for the sake of discussion): “look, this software has bugs, even
security bugs, so let’s not use it”. While I certainly would not want to
switch to an extremely buggy software myself either, I think we all know
that software is never entirely free of bugs. Expecting an absence of
bugs even before starting to use that software certainly is
unrealistic.

Moreover, consider that whole classes of bugs existed before, spread out
in the various init scripts, which are obsolete thanks to systemd’s
design, these two just being trivial examples off the top of my head:

• improperly sanitized environment, see e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=990321

• runaway scripts (e.g. cgi-bin) that spawn children and escape the main
daemon (e.g. apache2) being stopped.

Instead of focusing on the actual security issues, what I’d much rather
look at is the process with which such bugs are fixed. I.e. are security
problems acknowledged as such, are they fixed clearly and in a timely
manner? Are there enough eyes looking at the project to uncover, report
and collaborate in fixing the issues?

Also, and I think that should go without saying, if this branch of the
discussion is considered as reasoning against systemd in the decision
process, I’d like to see similar data on the other init systems :).

Thanks.

[Steve Langasek]

Post by Michael Stapelberg

Post by Ian Jackson
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.

They sure are. OTOH, chosing the init system that receives the most
attention in form of development and is adopted by many other
distributions helps us a lot with security issues. They are no longer
just our problem, but other distributions also care about getting them
fixed quickly.

All distributions "care" about not having security issues in their code, but
that's not the same thing as actually doing the work to audit the code. In
practice this only happens when dedicated resources are turned on the code
in question, and having more companies using the code does not magically
make that happen.

I don't know that the upstart code has been subjected to any sort of
comprehensive security audit. I also don't know whether the auditing that's
been done on systemd qualifies as comprehensive. I *will* assert that
upstart development is aimed at avoiding extraneous features precisely to
reduce the risk of bugs (security or otherwise).

Post by Michael Stapelberg

Post by Ian Jackson
There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
which I think a concurrent init system author ought really to be
competent to avoid. (And the system should be designed, so far as
possible, to reduce the opportunity for such races.)

systemd was not written by one author. It is also not concurrent (in
fact it is single-threaded and only links to pthreads to call sync
asynchronously on shutdown), but event-based. As for competency, I am
sure that everybody involved has learned their lesson and will avoid
such issues in the future.

Are the systemd developers novice programmers, that they need to learn to
program securely by trial and error?

The reality is that the kind of security bugs that we're talking about are
very subtle, and even experienced developers are going to make mistakes like
this from time to time, and as one of the arguments advanced for systemd is
that it has a large community of contributors, not all of those contributors
are going to be experienced developers. A project's security record has at
least as much to do with having a solid design to reduce the attack surface,
as it does with the developers' skill.

Post by Michael Stapelberg
I am also sure that other init systems have (had) similar bugs. And if
there is no evidence of that yet, maybe nobody looked really closely yet
?
:)

Unless you're offering to do a security audit of upstart, I don't think such
speculation changes anything.

[Moritz Mühlenhoff]

Post by Steve Langasek
All distributions "care" about not having security issues in their code, but
that's not the same thing as actually doing the work to audit the code. In
practice this only happens when dedicated resources are turned on the code
in question, and having more companies using the code does not magically
make that happen.

[I took care of the systemd DSA people are referring to]

The issue people are talking about were discovered during a review of
the Red Hat Product Security Team (most likely triggered by the inclusion
of systemd into RHEL7).
So in fact having more companies use the code exactly made that magically
happen.

For every complex code base a thorough review will unveil security-related
implementation bugs and the ones found for systemd are not exactly earth-
shattering.

More review and more usage will lead to more bugs being found, we should
rather applaud Red Hat for investing resources and be diligent. After all
Red Hat is the only distro staffing a proactive product security team
(from which everyone is profiting outside of RH as well). I don't consider
the lack of reported security issues for the contenders as a credible
indication of them being more secure.

FWIW, the main reason I'm personally in favour of adopting systemd is precisely
security (in terms of sandboxing and restricting services). See
http://0pointer.de/blog/projects/security.html for some pointers.

[EOD from me due to a lack of time, but that needed to be said]

Cheers,
Moritz

[Lars Wirzenius]

Post by Moritz Mühlenhoff
[EOD from me due to a lack of time, but that needed to be said]

And thank you for saying it.

[Steve Langasek]

Post by Moritz Mühlenhoff

Post by Steve Langasek
All distributions "care" about not having security issues in their code, but
that's not the same thing as actually doing the work to audit the code. In
practice this only happens when dedicated resources are turned on the code
in question, and having more companies using the code does not magically
make that happen.

[I took care of the systemd DSA people are referring to]
The issue people are talking about were discovered during a review of the
Red Hat Product Security Team (most likely triggered by the inclusion of
systemd into RHEL7).
So in fact having more companies use the code exactly made that magically
happen.

No, this is a function of one specific company having a proactive security
review policy (for which they should be commended). It has nothing to do
with how many companies are using the software.

Post by Moritz Mühlenhoff
More review and more usage will lead to more bugs being found, we should
rather applaud Red Hat for investing resources and be diligent. After all
Red Hat is the only distro staffing a proactive product security team
(from which everyone is profiting outside of RH as well). I don't consider
the lack of reported security issues for the contenders as a credible
indication of them being more secure.

Red Hat shipped upstart as their init system in RHEL 6. This did not result
in any CVEs being issued for upstart. What conclusions should we draw from
this?

Post by Moritz Mühlenhoff
FWIW, the main reason I'm personally in favour of adopting systemd is
precisely security (in terms of sandboxing and restricting services). See
http://0pointer.de/blog/projects/security.html for some pointers.

I think such built-in sandboxing features are interesting, but not decisive.
They represent an incremental improvement over the status quo for
sandboxing, and aren't anything that couldn't be delivered as a feature in
upstart, for example, if there were demand for it.

[Russ Allbery]

Post by Steve Langasek

Post by Moritz Mühlenhoff
The issue people are talking about were discovered during a review of
the Red Hat Product Security Team (most likely triggered by the
inclusion of systemd into RHEL7). So in fact having more companies use
the code exactly made that magically happen.

No, this is a function of one specific company having a proactive security
review policy (for which they should be commended). It has nothing to do
with how many companies are using the software.

I don't think that's strictly true. The more organizations use a piece of
software, the more likely one or more of them will have proactive security
review policies and will do such reviews. In other words, the size of the
community is relevant to how much security verification software gets.

Post by Steve Langasek
I think such built-in sandboxing features are interesting, but not
decisive. They represent an incremental improvement over the status quo
for sandboxing, and aren't anything that couldn't be delivered as a
feature in upstart, for example, if there were demand for it.

I don't think capability is really the discussion that we're having, at
least in the comparison between systemd and upstart's init components.
The question is more whether there are sufficient resources in the upstart
community that such development is likely.

[Raphael Hertzog]

Hi,

Post by Steve Langasek

Post by Moritz Mühlenhoff
More review and more usage will lead to more bugs being found, we should
rather applaud Red Hat for investing resources and be diligent. After all
Red Hat is the only distro staffing a proactive product security team
(from which everyone is profiting outside of RH as well). I don't consider
the lack of reported security issues for the contenders as a credible
indication of them being more secure.

Red Hat shipped upstart as their init system in RHEL 6.

The more interesting information in all this is why RHEL is switching over
from upstart to systemd?

I mean we have an incentive to switch to something else because we can't
reliably fix stuff with sysvinit. But if upstart was satisfactory at that
level, what are the reasons why RHEL is switching again?

Maybe the security features discussed here are part of the answer, I don't
know.

Post by Steve Langasek

Post by Moritz Mühlenhoff
FWIW, the main reason I'm personally in favour of adopting systemd is
precisely security (in terms of sandboxing and restricting services). See
http://0pointer.de/blog/projects/security.html for some pointers.

I think such built-in sandboxing features are interesting, but not decisive.
They represent an incremental improvement over the status quo for
sandboxing, and aren't anything that couldn't be delivered as a feature in
upstart, for example, if there were demand for it.

I believe that those who need those features just decide to use systemd
and won't "demand" those features to the upstart upstreams. In particular
when those features are of particular interest to people who are building
heavily customized systems (think embedded devices) and are not wary of
diverging from the defaults.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

[Moritz Muehlenhoff]

Post by Steve Langasek

Post by Moritz Mühlenhoff
More review and more usage will lead to more bugs being found, we should
rather applaud Red Hat for investing resources and be diligent. After all
Red Hat is the only distro staffing a proactive product security team
(from which everyone is profiting outside of RH as well). I don't consider
the lack of reported security issues for the contenders as a credible
indication of them being more secure.

Red Hat shipped upstart as their init system in RHEL 6. This did not result
in any CVEs being issued for upstart. What conclusions should we draw from
this?

None. The RH Product Security Team didn't exist back then (founded 1.5 years ago).

Cheers,
Moritz

[Ian Jackson]

[Ian Jackson:]

Post by Ian Jackson
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.

Post by Ian Jackson
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.

Statements like this are part of what make me think this might be a
fundamental problem. When a systemd proponent tells me that a
particular use pattern is unimportant or wrongheaded, I tentatively
infer that systemd cannot support it properly.

It seems to me that the difficulties with the runlevel emulation are
likely to affect other similar use patterns too. The problems don't
seem specific to the nature of runlevels. Perhaps they are specific
to the way runlevels are emulated by systemd but in that case that
emulation should surely be fixed.

[Ian Jackson:]

Post by Ian Jackson
There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
which I think a concurrent init system author ought really to be
competent to avoid. (And the system should be designed, so far as
possible, to reduce the opportunity for such races.)

systemd was not written by one author. It is also not concurrent (in
fact it is single-threaded and only links to pthreads to call sync
asynchronously on shutdown), but event-based.

systemd, like upstart, is concurrent in that it does more than one
thing at once. In particular, it does concurrent startup of
services.

One of the main potential advantages of a new approach to service
management is that it is less racy. This advantage depends on the
authors of the replacement having thought about the problems in the
right way, and not written racy code.

As for competency, I am sure that everybody involved has learned
their lesson and will avoid such issues in the future.

My point was that someone who is writing an init system for concurrent
startup and dynamic service management needs to have a good
understanding of concurrent system design, and in particular of race
hazards. I wouldn't expect a person or people who had such an
understanding to make many mistakes of the kind seen here.

Post by Ian Jackson
The "systemctl status" resource usage DoS (CVE-2012-1101) is an
understandable resource leak, given systemd's design. But for me it
raises this question: why is the system designed in such a way that
the critical pid 1 is required to implement functionality (and
unprivileged-facing interfaces) in which such a resource leak is (a) a
likely programming error and then (b) exposed so as to be exploitable.

a) I think “a likely programming error” is an exaggeration. Do you have
data on how often there were resource leaks in systemd?

AIUI from reading the advisories (I haven't read the code) this was a
simple memory leak bug.

b) I am unclear on how exactly this was exploitable, and the bugs lack
explanation unfortunately.

AIUI the exploit works as follows: the attacker runs "systemctl status
<blah>" where <blah> is a random invented unit name. They then repeat
this millions of times. Each time systemd allocates memory to record
this phantom unit; this memory is never freed. Eventually some kind
of resource is exhaused (e.g. RAM, address space, ulimit) and systemd
stops working properly.

Furthermore, I think Lennart’s explanation of why arbitrary units must
https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1

How was CVE-2012-1101 fixed ? That bug doesn't show the patch.

[later:]

I went and looked and found this:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=9a46fc3b9014de1bf0ed1f3004a536b08a19ebb3

It looks like the appropriate gc function was simply not called. As I
thought, an understandable programming error, but one which exists
only because of (perhaps essential) complexity in the code.

More importantly it is one which is exploitable only as a consequence
of the questionable design decision to expose pid 1 to ordinary users.

Post by Ian Jackson
AIUI the journald integer overflow (CVE-2013-4391) is a remotely
exploitable bug, if you have configured journald to allow remote
logging. (I assume this isn't the default configuration but haven't
checked.)

journald does not provide remote logging. See
https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html

Err, so I don't understand then why CVE report this vulnerability as
follows:

| Integer overflow in the valid_user_field function in
| journal/journald-native.c in systemd allows remote attackers to
| cause a denial of service (crash) and possibly execute arbitrary
| code via a large journal data field, which triggers a heap-based
| buffer overflow.

If journald doesn't support remote logging, how is this vulnerability
remotely exploitable ?

Personally, I don’t know about every little detail in fd passing
either. If I read you correctly, you seem to be saying one needs to be
an expert in a given area before being allowed to write code in it. I
think it works the other way around: by writing code in that area, you
become an expert in it.

What a startling statement. This is not some desktop toy we are
talking about; this is critical core system infrastructure.

I would prefer my pid 1 to have been written by experts. It appears
that you are saying that systemd wasn't and that this isn't important!

Instead of focusing on the actual security issues, what I’d much rather
look at is the process with which such bugs are fixed. I.e. are security
problems acknowledged as such, are they fixed clearly and in a timely
manner? Are there enough eyes looking at the project to uncover, report
and collaborate in fixing the issues?

I don't think having a functioning security response process is a
substitute for good system design, and a high initial code quality.

And I don't think that "many eyes" is as helpful as you apparently
think. Security code review is bloody hard work.

Also, and I think that should go without saying, if this branch of the
discussion is considered as reasoning against systemd in the decision
process, I’d like to see similar data on the other init systems :).

You are of course welcome to go and find that information.


Ian.

[Uoti Urpala]

Post by Ian Jackson

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.

Statements like this are part of what make me think this might be a
fundamental problem. When a systemd proponent tells me that a
particular use pattern is unimportant or wrongheaded, I tentatively
infer that systemd cannot support it properly.

At least here this logic led you to the wrong conclusion, so you might
want to reconsider it.

Post by Ian Jackson
It seems to me that the difficulties with the runlevel emulation are
likely to affect other similar use patterns too. The problems don't
seem specific to the nature of runlevels. Perhaps they are specific
to the way runlevels are emulated by systemd but in that case that
emulation should surely be fixed.

The issue was legacy runlevel changes being simply mapped to "isolate
new_runlevel", which does not have quite the same semantics as sysvinit
runlevel changes (most importantly, it stops everything not in the
new_runlevel target, without limiting to only things that were part of
original runlevel target). There's no reason why the set of services to
stop could not be calculated in a way closer to sysvinit semantics. But
there's little reason to deal with "runlevels" at all when using
systemd, and it seems most people don't. So while the backwards
compatibility support could be improved (probably rather easily), I
think it's clear why this has not been a priority for either developers
or users.

Post by Ian Jackson
More importantly it is one which is exploitable only as a consequence
of the questionable design decision to expose pid 1 to ordinary users.

I think there are good reasons to allow querying status directly. One
sanity check that IMO should be kept in mind for perspective when
considering any "even one DoS issue in PID 1 is a catastrophe" arguments
is that Debian will always require running a kernel, and there have been
lots of DoS or worse issues there. Unless you expect the majority of
Debian users to move to minimal microkernels in the near future, there
is little basis to demand an absolutely minimal init process when the
kernel contains much more code in a more critical role.

Post by Ian Jackson
and is being touted as the single systemwide manager for security
features like cgroups !

Parts of the implementation for this are on the kernel side, parts on
the systemd side. I see no reason to think that the systemd side would
be the more problematic one.

[Michael Stapelberg]

Hi Ian,

Post by Ian Jackson
My point was that someone who is writing an init system for concurrent
startup and dynamic service management needs to have a good
understanding of concurrent system design, and in particular of race
hazards. I wouldn't expect a person or people who had such an
understanding to make many mistakes of the kind seen here.

Neither do I, but there is no evidence for _many_ of these problems.

Post by Ian Jackson

Post by Michael Stapelberg
Personally, I don’t know about every little detail in fd passing
either. If I read you correctly, you seem to be saying one needs to be
an expert in a given area before being allowed to write code in it. I
think it works the other way around: by writing code in that area, you
become an expert in it.

What a startling statement. This is not some desktop toy we are
talking about; this is critical core system infrastructure.
I would prefer my pid 1 to have been written by experts. It appears
that you are saying that systemd wasn't and that this isn't important!

To clarify: I do think (most?) systemd authors are experts. I am also
saying that experts can make mistakes, and that having the expectation
that software has 0 bugs is unreasonable.

I also stand by my statement that one cannot be an expert in a subject
area before having experience in that subject area. Sure, one can
prepare, but there is the proverb “practice makes perfect”.

Post by Ian Jackson

Post by Michael Stapelberg
Instead of focusing on the actual security issues, what I’d much rather
look at is the process with which such bugs are fixed. I.e. are security
problems acknowledged as such, are they fixed clearly and in a timely
manner? Are there enough eyes looking at the project to uncover, report
and collaborate in fixing the issues?

I don't think having a functioning security response process is a
substitute for good system design, and a high initial code quality.

No argument there. I think having all three of them is better, and
that’s my opinion of systemd, at least of pid 1, which I have looked at
more closely than at the other parts of the larger system.

Post by Ian Jackson

Post by Michael Stapelberg
Also, and I think that should go without saying, if this branch of the
discussion is considered as reasoning against systemd in the decision
process, I’d like to see similar data on the other init systems :).

You are of course welcome to go and find that information.

I may be misunderstanding how this works, but I strongly believe that if
the ctte looks at the security track record of systemd, it MUST also
look at the security track record of the other contenders. I.e., I
consider it unfair to say “we’re not using systemd because it had
security bugs, we’ll chose X instead, but we didn’t look at its security
at all”.

That said, I’d love to help, but I don’t have the time to look at the
security track record of other init systems in detail. Sorry.

[Josselin Mouette]

Post by Ian Jackson
In summary, I agree with Andrew Kanaber's view that the security and
bug history of systemd is worrying.

Personally, I find the flow of bugs (including security bugs) for
moderately recent software the sign of a healthy project. A simple look
at a few packages in the BTS will show that packages with lots of
reported bugs are packages with lots of users and features, regardless
of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
to mind as being full of bugs, including security bugs.

Indeed, systemd has not been written with security in mind. Neither have
sysvinit nor upstart, AFAICT. Yes, it would be better if *all*
developers had a better grasp of secure programming, but on the other
hand, asking the first people to use some advanced kernel interfaces to
understand all their security implications is unfair. Just like we don’t
hold the Mozilla developers responsible for security issues in brand-new
Javascript engines that maybe 10 developers in the world could
understand.

As Michael mentioned, systemd has a broader scope than alternatives.
You’d have to use a system providing similar features as a basis for a
fair comparison, and such a system doesn’t really exist in the Unix
world. If you only take into account the features that are also provided
by upstart or sysvinit/insserv, you won’t find that many of these bugs
apply. Compare that to the number of unfixable bugs in sysvinit due to
broken design.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Ian Jackson]

Post by Josselin Mouette
Personally, I find the flow of bugs (including security bugs) for
moderately recent software the sign of a healthy project. A simple look
at a few packages in the BTS will show that packages with lots of
reported bugs are packages with lots of users and features, regardless
of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
to mind as being full of bugs, including security bugs.

All of those components are to a greater or lesser extent optional.
What we are being asked is to make use of systemd mandatory.

Post by Josselin Mouette
Indeed, systemd has not been written with security in mind.

What an alarming comment on a program which has ultimate privilege, is
intended to be universally deployed even in the most demanding
security environment, crosses security boundaries (without, IMO, a
sufficient justification), and is being touted as the single
systemwide manager for security features like cgroups !

Post by Josselin Mouette
Neither have sysvinit nor upstart, AFAICT.

I will leave the upstart maintainers to comment on this in more
detail, but sysvinit has had remarkably few security bugs for a
program of its vintage. This is because it has very few, and very
restricted, interfaces to untrusted parts of the system.

Post by Josselin Mouette
Just like we don’t hold the Mozilla developers responsible
for security issues in brand-new Javascript engines that maybe 10
developers in the world could understand.

The security record of web browsers is indeed atrocious. It is the
result of a persistent swamp of bad design decisions, hideous
overcomplexity, plain bad code, and lack of attention to mitigation
measures. Google's efforts in this area are to be applauded, even
though I have serious privacy problems with Google.

It is very alarming that web browsers are being presented as the
security benchmark for our new init system.

Ian.

[Josselin Mouette]

Post by Ian Jackson

Post by Josselin Mouette
Personally, I find the flow of bugs (including security bugs) for
moderately recent software the sign of a healthy project. A simple look
at a few packages in the BTS will show that packages with lots of
reported bugs are packages with lots of users and features, regardless
of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
to mind as being full of bugs, including security bugs.

All of those components are to a greater or lesser extent optional.

Linux is optional?
X is optional? Not for everyone. (X is a bad example anyway, because,
unlike the rest, it *has* a bad security design.)

Post by Ian Jackson
What we are being asked is to make use of systemd mandatory.

It doesn’t mean that all of systemd’s features should be enabled on all
machines. The reason why embedded manufacturers are sponsors for
systemd’s development is that it means less code, and therefore less
bugs (security or not), than alternatives.

Post by Ian Jackson

Post by Josselin Mouette
Indeed, systemd has not been written with security in mind.

What an alarming comment on a program which has ultimate privilege, is
intended to be universally deployed even in the most demanding
security environment, crosses security boundaries (without, IMO, a
sufficient justification), and is being touted as the single
systemwide manager for security features like cgroups !

Only an extreme minority of Debian packages have been written with
security in mind. Not all packages can be OpenSSH or Postfix, and we
have to live with that fact, because we need the features in other
packages (starting with a kernel and libc).

Post by Ian Jackson

Post by Josselin Mouette
Neither have sysvinit nor upstart, AFAICT.

I will leave the upstart maintainers to comment on this in more
detail, but sysvinit has had remarkably few security bugs for a
program of its vintage. This is because it has very few, and very
restricted, interfaces to untrusted parts of the system.

And of course, there has never been any buggy init script.

Again, your comparison doesn’t make any sense since you don’t compare
similar functionality scopes.

Post by Ian Jackson

Post by Josselin Mouette
Just like we don’t hold the Mozilla developers responsible
for security issues in brand-new Javascript engines that maybe 10
developers in the world could understand.

The security record of web browsers is indeed atrocious. It is the
result of a persistent swamp of bad design decisions, hideous
overcomplexity, plain bad code, and lack of attention to mitigation
measures. Google's efforts in this area are to be applauded, even
though I have serious privacy problems with Google.

I’m afraid you don’t entirely understand why the security record of web
browsers looks atrocious. Because of a swamp of bad decisions *from web
developers and designers*, backed by users, browsers have to cover a
functional scope that far exceeds in complexity any other kind of
software. A typical browser has to include several virtual machines,
graphical/layout toolkits, JIT compilers, advanced cryptographic
software, all of which have to work with heaps of untrusted data. When
taking all of that into account, as much as I hate dealing with them, I
have to admit the security record for several browsers is good, and it’s
because they *are* developed with security in mind.

Post by Ian Jackson
It is very alarming that web browsers are being presented as the
security benchmark for our new init system.

It is quite alarming that a member of the Technical Committee
demonstrates lacks in security knowledge while at the same time using
security bugs as a measure for comparing solutions.


This “security” discussion has nothing to do with the case in point,
though. If you have specific points you want addressed by the systemd
position (like how systemd’s upstream designs user interfaces to avoid
security bugs, or handles security alerts), please state them clearly
and I will do my best to gather information for you and answer them.
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Andreas Barth]

Post by Josselin Mouette
It is quite alarming that a member of the Technical Committee
demonstrates lacks in security knowledge

I would prefer if you could stop doing ad-hominem attacks (independend
on whom - this is not an acceptable behaviour).


Andi

[Paul Tagliamonte]

Post by Ian Jackson
It is very alarming that web browsers are being presented as the
security benchmark for our new init system.

So, I tend to agree with Joss here - Web browsers is the biggest attack
surface that we have today, bar none. I don't think anyone really
disputes this.

The safety of modern web browsers is (well, minus a qualifier below), frankly,
shockingly good.

The amount of exploits from JS is crazy low for something that's able to
do so much (store data locally, use WebGL / 3D rendering, play audio),
it is shockingly hard to exploit.

When you look at the entire stack (CSS parsers / evaluators, HTML
parsers & evaluators, JS parsers and evaluators), the only disaster
would be stuff like ActiveX. I'm not sure of it's state, since I've
never run a platform that supports it, but I hear it's getting better.

So, yes, browsers are a cespool, but it's one that runs complete garbage
on the internet.

I'd be stunningly happy to see an init system that can handle as much
pure crap as browsers have to put up with :)


More on-topic, I do think that the systemd bugs are more likely because
people are playing with the code, exploring it for holes, and pushing
them, which is healthy. I'm sure if you poked hard enough, most systems
would show such bugs. (as has been already said, really)


Cheers,
Paul

[Steve Langasek]

Post by Josselin Mouette
Indeed, systemd has not been written with security in mind. Neither have
sysvinit nor upstart, AFAICT.

I wouldn't presume to say whether the systemd authors had security in mind
while writing it. But I will stand by the overall security design of either
sysvinit or upstart, namely that the user-accessible interfaces are kept as
small as possible to make them as auditable as possible.

[Josselin Mouette]

Post by Josselin Mouette
Indeed, systemd has not been written with security in mind.

Obviously, such a subjective judgment of valor does not mean the same to
me as to other developers. It is easy to quote it out of context and say
“oh, look! some systemd advocate said that it is insecure! of course MY
init system of choice is more secure!”, but it is merely a fallacy since
we are not talking about the same thing.

Therefore, I have to retract this statement.
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Sune Vuorela]

Post by Ian Jackson

CVE summary Debian BTS Redhat
2012-0871 systemd-logind insecure file creation ? 795853

Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
the systemd codebase when assessing the likely code quality of the pid
1 parts.

Note that the non-pid1-parts of systemd, like logind for example, are pieces
we need no matter what init system we choose. The question is more if we can
use them as provided by upstream or we need to adapt them in Debian.

/Sune
--
How to close the space bar?

First from the control drawer inside Office 8.7.5 you should ping the site of
the controller for logging on a BIOS.

[Ian Jackson]

Post by Sune Vuorela
Note that the non-pid1-parts of systemd, like logind for example, are pieces
we need no matter what init system we choose. The question is more if we can
use them as provided by upstream or we need to adapt them in Debian.

Whether Debian' "uses" something is a lot more granular than that.
It seems to me that there are plenty of systems which could do without
logind, at least if we're not using systemd as pid 1.

This leads me to a question which I find myself asking, after reading
the systemd debate page:

If we were to adopt systemd as pid 1, which sections of the systemd
source code would we probably want to adopt as well ? Or to put it
another way, which other existing programs would be obsoleted ?

This is important for two reasons that I can think of:

Firstly, it is touted as an advantage of systemd that it provides in a
good and proper way this other functionality; it seems that the
systemd designers consider that these other ad-hoc programs or
facilities are crufty and in need of replacement. So I would like to
know which these other facilities are, that are going to be improved.

Secondly, if we are, for example, to compare the total LOC count, or
the bug list, or the CVE history, of systemd, with that of a
non-systemd system, we need to know which parts of the old system are
replaced.

Ian.

[Sune Vuorela]

Post by Ian Jackson
This leads me to a question which I find myself asking, after reading
If we were to adopt systemd as pid 1, which sections of the systemd
source code would we probably want to adopt as well ? Or to put it
another way, which other existing programs would be obsoleted ?

logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or
not a user is sitting on the physical console or logged in. libpam-xdg ensures
that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures
that a user session actually can be terminated when she logs out.

Logind is the most important one, and within a year or two all desktop
environments that wants to be slightly more advanced than TWM is going to need
it. Even Ubuntu is using logind and is iirc maintained there by Steve
Langasek.

Consolekit was written by the same people as involved in systemd and is now
hopefully getting it right. Consolekit is abandoned upstream a couple of years
ago. Libpam-xdg was written by Steve Langasek for Ubuntu and has since been
abandoned in in Ubuntu favour of the systemd bits .

Beside that, there are among others:
the timezoned is ensuring a common way that applications can get notified when
the hosts timezone changes. KDE does have something for that that would be
obsoleted. I think most other systems requires restart of applications or
manual magic in each app.

hostnamed is for notifying when hostname changes. KDE does have something for
that. I don't know who else.

There are more parts, but that's where my research has ended so far.

/Sune
--
How to cancel a mailer to the proxy from Flash and from the folder inside DOS
97?

You must log on a driver to debug a monitor.

[Steve Langasek]

Post by Sune Vuorela

Post by Ian Jackson
This leads me to a question which I find myself asking, after reading
If we were to adopt systemd as pid 1, which sections of the systemd
source code would we probably want to adopt as well ? Or to put it
another way, which other existing programs would be obsoleted ?

logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether
or not a user is sitting on the physical console or logged in. libpam-xdg
ensures that XDG_RUNTIME_DIR is handled according to the spec). Logind
also ensures that a user session actually can be terminated when she logs
out.
Logind is the most important one, and within a year or two all desktop
environments that wants to be slightly more advanced than TWM is going to
need it. Even Ubuntu is using logind and is iirc maintained there by
Steve Langasek.

It's collectively maintained in Ubuntu; I do help with it, but Martin Pitt
does most of the routine maintenance for the systemd source package (udev,
logind).

Post by Sune Vuorela
the timezoned is ensuring a common way that applications can get notified
when the hosts timezone changes. KDE does have something for that that
would be obsoleted. I think most other systems requires restart of
applications or manual magic in each app.

'timedated'

Post by Sune Vuorela
hostnamed is for notifying when hostname changes. KDE does have something
for that. I don't know who else.
There are more parts, but that's where my research has ended so far.

The other one that GNOME uses, and that should be adopted, is localed.

But these dbus services (logind, timedated, hostnamed, localed) are things
that we should adopt, /independently/ of whether systemd is used as pid 1.

I don't know that there are any systemd services that we would want to adopt
IFF we switched to systemd for pid 1.

[Russ Allbery]

Post by Ian Jackson
If we were to adopt systemd as pid 1, which sections of the systemd
source code would we probably want to adopt as well ? Or to put it
another way, which other existing programs would be obsoleted ?

Yes, that's a good question. We're already using udev, which is now part
of systemd as I understand it. We'll clearly want to use logind for at
least GNOME (Ubuntu already does that), and I suspect for other desktop
environments as well. I think there are some other pieces that may
replace other currently separate desktop components.

It sounded like the new D-Bus service may also be important for desktop
environments.

Another point here is that it's sounding like we'll be using a lot of
those services regardless, at least on systems that need them, which means
that their security track record and bug rate is somewhat irrelevant for
this discussion provided that running systemd doesn't force them to be
running on systems that don't need them. For example, if desktop
environments using upstart are still going to be running logind, the
logind part loses nothing from running systemd and gains something (easier
integration that we don't have to maintain ourselves). Similarly for
udev.

[Ian Jackson]

Post by Russ Allbery
Another point here is that it's sounding like we'll be using a lot of
those services regardless, at least on systems that need them, which means
that their security track record and bug rate is somewhat irrelevant for
this discussion provided that running systemd doesn't force them to be
running on systems that don't need them. [...]

I don't think that's entirely true. I think it is fair to look at the
security history of other parts of the same project as indicative
regarding code quality.

Ian.

[Josselin Mouette]

Post by Ian Jackson
I don't think that's entirely true. I think it is fair to look at the
security history of other parts of the same project as indicative
regarding code quality.

There are two implied assumptions here:
* that the same people are developing all components;
* that develolpers have the same attention to code quality and
security in all components they work on.

I don’t think either of them applies to systemd.
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Bdale Garbee]

Post by Josselin Mouette
* that the same people are developing all components;
* that develolpers have the same attention to code quality and
security in all components they work on.
I don’t think either of them applies to systemd.

Right, this succinctly captures one of my biggest concerns about systemd.

Bdale

[Josselin Mouette]

Post by Bdale Garbee

Post by Josselin Mouette
* that the same people are developing all components;
* that develolpers have the same attention to code quality and
security in all components they work on.
I don’t think either of them applies to systemd.

Right, this succinctly captures one of my biggest concerns about systemd.

Could you please elaborate on this concern? Is it about the large number
of developers, or about the fact they treat important pieces of code
more carefully?
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Don Armstrong]

Post by Josselin Mouette

Post by Bdale Garbee

Post by Josselin Mouette
* that the same people are developing all components;
* that develolpers have the same attention to code quality and
security in all components they work on.
I don’t think either of them applies to systemd.

Right, this succinctly captures one of my biggest concerns about systemd.

Could you please elaborate on this concern? Is it about the large number
of developers, or about the fact they treat important pieces of code
more carefully?

Projects which have multiple components, each of which has different
security/interface surfaces without stable defined interfaces, can lead
to problems when one set of developers doesn't understand the security
implications of the parts that they do not work on.

The combination of components into a single monolith is sometimes
necessary, but it's not clear that it is so in the case of systemd.
--
Don Armstrong http://www.donarmstrong.com

THERE IS NO GRAVITY THE WORLD SUCKS
-- Vietnam War Penquin Lighter
Loading Image...

[Uoti Urpala]

Post by Don Armstrong

Post by Josselin Mouette

Post by Bdale Garbee

Post by Josselin Mouette
* that the same people are developing all components;
* that develolpers have the same attention to code quality and
security in all components they work on.
I don’t think either of them applies to systemd.

Right, this succinctly captures one of my biggest concerns about systemd.

Could you please elaborate on this concern? Is it about the large number
of developers, or about the fact they treat important pieces of code
more carefully?

Projects which have multiple components, each of which has different
security/interface surfaces without stable defined interfaces, can lead
to problems when one set of developers doesn't understand the security
implications of the parts that they do not work on.
The combination of components into a single monolith is sometimes
necessary, but it's not clear that it is so in the case of systemd.

IMO "single monolith" is bad terminology - to me that sounds something
like everything in a single process, while the systemd components are
quite modular.

"Not clear it's necessary" seems like an overly negative attitude. There
doesn't seem to be much disagreement about the fact that many of the
systemd components are very useful and would be used even with a
different init. The above security considerations seem purely
theoretical, with no sign that they'd be an issue with systemd in
practice. And IIRC no other actual technical problems resulting from
developing the components together have been brought up in this thread
either. So why should it be done any differently, when this way appears
highly successful?

[Russ Allbery]

Post by Don Armstrong
Projects which have multiple components, each of which has different
security/interface surfaces without stable defined interfaces, can lead
to problems when one set of developers doesn't understand the security
implications of the parts that they do not work on.

It's unclear to me that this is a correct characterization of systemd. Do
the separate components of systemd not have stable, defined interfaces? I
know they largely don't have other implementations, but that's not the
same thing.

Post by Don Armstrong
The combination of components into a single monolith is sometimes
necessary, but it's not clear that it is so in the case of systemd.

systemd is a large package from a source code perspective, but it's not my
impression that the result of building that source is a monolith. Rather,
it's a variety of separate, interoperating services, which strikes me as a
good general model. In fact, that design is what makes it possible to
consider using upstart and still support GNOME, since it means that logind
is separable from systemd with some effort. That strongly implies that
systemd is not a monolith.

I think the concern on the systemd side is not stemming from unstable
interfaces but from *evolving* interfaces, which is not the same thing.
In other words, the current systemd services do not implement all the
functionality that will be eventually needed, particularly by desktops, so
those interfaces will grow with time, and may require further D-Bus, udev,
cgroups, and similar integrations.

Let me put it this way. I think there are a couple of givens here, some
of which have been expressed by both the GNOME maintainers and the KDE
maintainers and which are also reflected by the current state of Ubuntu:

* We use udev as the default device management platform and will continue
to do so regardless of the init system we choose.

* Many of the other systemd services, particularly logind but also several
of the others, are quite desirable or even necessary for desktop
environments, so we will need to adopt those services in Debian
regardless of what init system we choose. Obviously, if we adopt
systemd, integrating those services into the distribution is quite
straightforward. If we don't adopt systemd, there are some critical
missing integrations (relative to the normal systemd infrastructure)
that will have to be replaced. The cgroups manager appears to be the
most significant one at the moment.

If the interfaces for those supplemental components are actually unstable,
that's going to pose problems all around, but I'm not sure how directly
relevant to this discussion that is since we're going to have to deal
with those components *anyway*. Choosing a different init system than
systemd is not going to let us ignore logind, since it's going to be a
required component for a modern desktop. (Although it would still be good
to know if this is the case.)

[Tollef Fog Heen]

]] Russ Allbery

Post by Russ Allbery

Post by Don Armstrong
Projects which have multiple components, each of which has different
security/interface surfaces without stable defined interfaces, can lead
to problems when one set of developers doesn't understand the security
implications of the parts that they do not work on.

It's unclear to me that this is a correct characterization of systemd. Do
the separate components of systemd not have stable, defined interfaces? I
know they largely don't have other implementations, but that's not the
same thing.

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

has a table with the various interfaces and their status.

[...]

Post by Russ Allbery
Let me put it this way. I think there are a couple of givens here, some
of which have been expressed by both the GNOME maintainers and the KDE
* We use udev as the default device management platform and will continue
to do so regardless of the init system we choose.

Agreed.

Post by Russ Allbery
* Many of the other systemd services, particularly logind but also several
of the others, are quite desirable or even necessary for desktop
environments, so we will need to adopt those services in Debian
regardless of what init system we choose. Obviously, if we adopt
systemd, integrating those services into the distribution is quite
straightforward. If we don't adopt systemd, there are some critical
missing integrations (relative to the normal systemd infrastructure)
that will have to be replaced. The cgroups manager appears to be the
most significant one at the moment.
If the interfaces for those supplemental components are actually unstable,
that's going to pose problems all around, but I'm not sure how directly
relevant to this discussion that is since we're going to have to deal
with those components *anyway*. Choosing a different init system than
systemd is not going to let us ignore logind, since it's going to be a
required component for a modern desktop. (Although it would still be good
to know if this is the case.)

TTBOMK, the page listed above is accurate, and yes, I think there are
components we should adopt no matter if we go for systemd or not.
Things like tmpfiles.d aren't terribly complex, but it adds complexity
to each and every init script that needs a writable directory in /run to
handle permissions, ownership and creation, rather than just having a
single declarative file listing what it needs and the bootup process
ensuring that exists.

[Don Armstrong]

Post by Tollef Fog Heen
]] Russ Allbery

Post by Russ Allbery

Post by Don Armstrong
Projects which have multiple components, each of which has
different security/interface surfaces without stable defined
interfaces, can lead to problems when one set of developers
doesn't understand the security implications of the parts that
they do not work on.

It's unclear to me that this is a correct characterization of
systemd. Do the separate components of systemd not have stable,
defined interfaces? I know they largely don't have other
implementations, but that's not the same thing.

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
has a table with the various interfaces and their status.

This was useful; thanks for linking to this.

[...]

Post by Tollef Fog Heen

Post by Russ Allbery
If the interfaces for those supplemental components are actually
unstable, that's going to pose problems all around, but I'm not sure
how directly relevant to this discussion that is since we're going
to have to deal with those components *anyway*.

Right; I think we definitely should integrate many of the components
that are being developed. I'm just concerned that the
component<->systemd interface is still changing, and because the
codebase is integrated, there's less of a requirement to communicate and
document what that interface is than there would be if they were
distinct projects.

This concern isn't very strong, but it was piqued when udev development
was brought into systemd; I'm still not certain why that was necessary.
--
Don Armstrong http://www.donarmstrong.com

It is easier to build strong children than to repair broken men.
-- Frederick Douglass

[Russ Allbery]

Post by Ian Jackson

Post by Russ Allbery
Another point here is that it's sounding like we'll be using a lot of
those services regardless, at least on systems that need them, which
means that their security track record and bug rate is somewhat
irrelevant for this discussion provided that running systemd doesn't
force them to be running on systems that don't need them. [...]

I don't think that's entirely true. I think it is fair to look at the
security history of other parts of the same project as indicative
regarding code quality.

Oh, sure, I do understand that part. But when trying to draw inferences
there, it's also important to realize that several of those components
were amalgamated after the fact and had different original authors.
systemd is quite the large tent project right now.

[Sergey B Kirpichev]

Post by Ian Jackson
If we were to adopt systemd as pid 1, which sections of the systemd
source code would we probably want to adopt as well ? Or to put it
another way, which other existing programs would be obsoleted ?

Again, very good question. And answer to this on the debate page is
very worrying, assuming that security concerns were unresolved yet.
(e.g.: CVE-2012-1101 or CVE-2013-4393 examples in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#583)

Personally, as maintainer of the monit package I have objections

Post by Ian Jackson
Systemd’s service monitoring replaces most uses of daemontools,
runit, monit, and maybe other similar packages.

This may be correct for daemontools/runit, but not for monit or any
other application-level utility ("if failed port 80 protocol http and
request ... then restart") for proactive monitoring (for example,
zabbix has similar functional).

But systemd can cause conflicts (this depends on the adopted
systemd's default configuration) and so, can create hard-to-debug problems here.

Post by Ian Jackson
Most of these bugs have been found by the Red Hat Product security
team conducting an audit of the code as part of its inclusion in
their enterprise distribution. Therefore, systemd's security record
cannot reasonably be compared with implementations that didn’t
undergo similar audits.

Both upstart and sysvinit were part of RHEL. Please explain
the difference.

PS:
And just a side note. It's only my own impression,
that there is too many hate/love around systemd?
Personally, during conversation with the systemd's
wiki page maintainer, I was impressed how many prejudments
he can made and how fast (already after the first letter).
This public disscussion is not an exception:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#628

Why nginx author doesn't have any needs to explain why his
software is superior to apache/lighttpd/etc in vast range
of usecases and so on? And this is not unusual for other
projects. Why?

If this situation is so specific for systemd, we
should count this as an argument against. Is there
any similar example from the debian history?