On Fri, 2013-11-29 at 12:37 +0000, Ian Jackson wrote:
> Uoti Urpala writes ("Bug#727708: systemd (security) bugs (was: init system
> question)"):
> > 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.
> 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.
> 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.
The same applies to this:
> 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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
