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

[zap]

   On 02/15/2017 05:12 PM, Luke Kenneth Casson Leighton wrote:
> 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.
Very insightful, never knew that selinux and systemd had such
compatiblity issues when used together...

gufw probably has similiar issues I am guessing...

Yeah... I am beginning to agree. if you cannot restrict attack vectors
when systemd is in the system then there is a problem. and I have a
feeling there are more issues unknown lurking underneath the surface
that have yet to be revealed.  Thanks for enlightening me Luke.

> l.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk