[Arm-netbook] A suggestion why Systemd may be bad

[Luke Kenneth Casson Leighton]

On Wed, Feb 15, 2017 at 9:29 PM, John Luke Gibson <eaterjolly at gmail.com> wrote:
> I appreciate the explanation. My premise was based on the linux sucks
> video sequel which argued that many people thought systemd was messy
> because it wasn't minimalist enough.
>
> If the code of the init system is not getting expanded by interweaving
> component files, that leaves me curious what it is getting expanded
> by. I presume that might be extra firmware for more support of more
> hardware, but idk.

 the scope creep is what has people who have security knowledge deeply
concerned.  expansion into management of network firewall rules,
ability to kill and spawn processes (all this is in PID 1) - and it's
*in development* rather than having been declared under a roadmap many
years ago.

 they've violated ISO 9001 so many times that far from being able to
trust the developers of systemd to rein in their continued expansion,
the *complete opposite* is the case.

 for a good indication of the extent of the problem, you can look at
the SE/Linux permissions for systemd.  it will be... worryingly
extensive.

 the FLASK model was designed based around the principle of "no
permissions unless necessary".  it's fully recognised that executables
(exec) is the only safe way to ensure a boundary.  fork is clearly not
ok: it allows memory, as well as file handles, to be shared between
processes.

so the only way to gain additional privileges would be to run a
*SEPARATE* executable (which is again a controlled operation) using a
tuple:

 * name of executable currently running
 * user-context (or equivalent in SE/Linux)
 * name of executable to be exec'd (note: NOT forked.  fork carries
over too much to be trusted)
 * new user-context (equivalent thereof) under which executable is to be run

within the new user-context, an ENTIRELY SEPARATE set of permissions
is associated.  a good way to think of this is for a 5 star general to
go to a NATO army base.  at the gate, the 5 star general's Military ID
is *TAKEN AWAY* just like everyone else's and is replaced with a
badge.  he gets his ID back (just like anyone else) when he leaves the
base.

on the replacement badge it is coded with time, date and the
*specific* doors that he is allowed to open with it, as scheduled per
his visit...  just like everyone else.

if he tries to leave the base without his Military ID, he can't get on
the plane to get back to the USA.  doesn't matter that he's a 5 star
general.

this is exactly how SE/Linux works.

systemd doesn't violate SE/Linux "per se" but it violates the
*principle* for which SE/Linux was designed (to restrict attack
vectors), by demanding - in a single process - so many permissions
that you might as well not even bother *running* SE/Linux in the first
place.

it seems that there are very few people in the linux community who
actually understand this - that trusting systemd to manage so much is
*really* dangerous, particularly given the track record of the systemd
developers.  no, having separate processes (such as logind) which
manage certain aspects via a d-bus (or other) network interface is not
an answer, if it's managed by something that's been totally
compromised it allows the components it's *communicating* with to be
compromised as well.

i don't explain this stuff to people because i expect them to know it.
i thought it wasn't my role to explain it to people, because i'm now
focussing on hardware design, not security analysis and threat
assessment: i haven't dealt with that stuff in almost 15 years now.

l.