Bug#727708: systemd (security) bugs (was: init system question)
On Sun, Dec 01, 2013 at 09:50:49PM +0000, Ian Jackson wrote:
> 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
against statement:
> 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.
Another questionable statement:
> 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?
Reply to: