On Wed, Feb 15, 2017 at 9:29 PM, John Luke Gibson eaterjolly@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.