Part of the issues about the ATT or BSD init systems had to do with
"local control" and with captive markets -- the latter a deliberate
choice by the profit-controllers to the engineers and implementers.
This is the old interplay between proprietary (often controlled by
"intellectual property" because the entity has sufficient patent
attorneys to gain such "property" that can then be used to prohibit the
development of an innovation to maintain revenue generation) and open
standards. The same reason that most threaded fasteners on vehicle
manufacturer A and B are readily available and interchangeable if the
same choice of thread, grade, form, etc., were used, whereas engines are
proprietary.
I fully agree that a full security audit would be valuable, an audit
that needs to be kept current. Nonetheless, "lines of code" is a well
established empirical metric, given the approximate number of execution
("run time") software defects in syntactically correct source code based
on the lines of code in the source. I am not defending "lines of code",
merely repeating what is a standard "rule of thumb".
My bigger concern is that SystemD is no longer used on an isolated
system in a segregated environment (NB: that term has nothing to do with
socio-political contexts -- please do not misinterpret it as have some
non-CSE colleagues when hearing of that, "race conditions", and other
CSE specific terminology). The larger the distributed (and integrated
or inter-dependent) the environment is, particularly over the public
Internet (even with VPNs or the like), the greater the risk of
compromise through vulnerabilities. Hardening systems is not easy, and
there are as yet no definite algorithms (let alone implementations) to
detect vulnerabilities pre-exploit. Obviously, methods to control
memory leaks in certain programming languages, etc., help -- but unless
source code is available, and verification of correctness of the
compiler (binary or "byte-code") output, there is no guarantee that such
have been implement. SystemD is open -- so in principle the coding
issue could be addressed, but such is not the case for closed systems,
no source code available.
Were the init systems more resilient? These were never designed for the
current wide area network platforms and environments such as "cloud
computing" -- thus it is very unlikely that these perform better. The
issue comes back to the bloat in SystemD overseeing, in some sense,
"everything". As such, it is a possible single point of failure, or
exploit.
However, lacking data and the person power to both accumulate and
understand such data, this discussion is more speculative than empirical
-- "philosophy", not "science". If a major vulnerability is exploited
through SystemD (as recently was revealed for a proprietary distributed
update environment, not SystemD), the consequences will affect more than
just the community of SL.
On 1/25/21 10:05 AM, Lamar Owen wrote:
On 1/25/21 12:04 PM, Yasha Karant wrote:
The question is: what mechanism? The reality today for Linux systems
as deployed at scale mostly is SystemD. The question -- a question
that goes well beyond what started as an exchange about EL 8 -- is
what goes forward? SystemD as it currently stands is too delicate and
too vulnerable to compromise, either within itself or in terms of the
processes/subsystems it "controls", despite the large scale deployment
of SystemD. ...
This statement begs some proof (preferably a formal code audit) of the
stated opinion that systemd is too 'delicate' and vulnerable to
compromise. Anecdotal evidence or counting LoC and saying 'more LoC =
automatically more vulnerable' need not apply. Of course, all code is
vulnerable, but the implication is that systemd is by nature more
vulnerable because $reason where $reason is something other than a
formal audit.
I asked a question to which I have not seen an answer: does a SystemD
configuration (plain text files in the SystemD design) from two
similar hardware platforms but different Linux distros (say, EL and
LTS) interoperate, or require significant rewriting to produce the
"same results"? In other words, are the valuable concepts of
portability and re-usability (do not reinvent the wheel, another
engineering turn of phrase) met in practice with SystemD?
The systemd unit files are more portable than old initscripts, in my
experience. The determining factors will be whether the distributions'
engineers pick the same names for the services started by the unit file
and if the paths to executables are the same or not. The main
differences here are the same as the differences in the locations of
files between the major branches of the Linux filesystem hierarchy;
Debian and derivatives will be different from Red Hat and derivatives,
to pick the two top examples.
Old initscripts were and are highly dependent upon the functions sourced
from the distribution's function library for initscripts, as well as
paths and daemon/service name; chkconfig metadata differences; and, of
course, they are executing as root in the system shell, and shell
quoting and escaping syntax becomes critical (the initscript for an
autossh instance, for instance, with say a half dozen reverse tunnels; I
have a few of those around here). I wrote a few for PostgreSQL for use
on several different RPM-based systems; there was quite a variety, and
SuSE did things differently from Red Hat which did things differently
from TurboLinux (one of the targets of my packaging), and others did
things yet more differently. It's possible to write initscripts to be
very portable, but it is harder than writing a unit file that can be
portable, as far as I can see. But I do always reserve the right to be
wrong.
In practice a unit file from an upstream project, especially if the
project uses /opt/$progname or /usr/local/{bin|lib}, will be very
portable across distributions. This I have experienced; a single unit
file can pretty easily be written to work across all systemd
distributions unless it needs some distribution-specific daemon/service
or feature.
