On 1/25/21 1:34 PM, Yasha Karant wrote:
> ...
> 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".
>
While I have not counted to see, the number of distributed lines of code 
in the initscripts pulled in by individual packages should also be 
counted, along with the LoC of bash itself.  LoC has been used as a 
rough rule of thumb in the past, but a formal audit is more accurate.  I 
would imagine Red Hat audits the systemd code internally, but I don't 
have any direct evidence of that.

> 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).  ...

Understood; as I come from a hardware engineering background I 
understand the potential impacts of 'synchronous asynchrony' and how 
conditions can develop that are very timing-sensitive and 
nondeterministic in behavior; the overall label of 'race condition' is 
used; the most easily explained example I know of is of a four-way stop, 
and all four cars arrive at the intersection simultaneously (within 
human-perceived tolerances, at least).  Which of the four has the right 
of way?

This was sometimes a significant issue with old initscripts.

> 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.

It's a common misconception that systemd is one monolithic binary trying 
to do all the things it does; this is not the case.  It IS a large set 
of programs, but each of those is relatively self-contained; see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Systemd&d=DwIFAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=pmFyZxsNsGEEYJrcr1FAHWhR-i0LgsbLzEnn12ie7Ag&s=8X0vrNtKYURepsfpHmXakirpVwIFY6biFz6zMzgfzes&e=  for the overview.

But systemd is the name of both the collection of these programs and the 
executable running as PID 1; more than a bit confusing.  Make no 
mistake: it is quite a bit larger than Upstart's init (from EL6) or 
EL5's actual SysV Init, but it's not fair to compare just the code size 
of the init process; the init runs all these scripts that are 
interpreted by the system shell; if that's bash, then the code size 
difference is not nearly as large.  With bash running the initscripts as 
root under the direct control of PID 1, bash must be considered part of 
the init system and thus becomes a link in the vulnerability chain.  The 
chain is only as strong as its weakest link; in sysvinit the collection 
of interrelated initscripts that execute as root is easily the weakest 
link; in systemd it's the relatively large PID 1.