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

[Luke Kenneth Casson Leighton]

On Wed, Feb 15, 2017 at 10:25 PM, zap <zapper at openmailbox.org> wrote:

> Very insightful,

 thx.  i just... don't explain this stuff very much any more as i
expect people to know it.  also, i didn't (and still don't) get paid
for the expertise i'm aware of, so don't have an established
reputation where people would actually *listen*.... so i remain silent
instead.

> never knew that selinux and systemd had such
> compatiblity issues when used together...

 correction of possible misunderstanding: systemd is just "an
executable" (or set thereof).  selinux is: "a system for monitoring
*and specifying* in a formal language the permitted behaviour and
interaction *of* executables".  you can just as equally well drop
selinux on top of sysvinit scripts, and anything else, all the way
down to individual X11 system calls if you really want to.  it just
takes a hell of a long time to work out useful selinux privileges, so
most people don't bother.

 caveat: i haven't done the expansion of the macros myself in order to
do a full analysis (because i don't use selinux any more) - simply
haven't got time.  i'm pointing out that anyone who *wants* to can do
so (and confirm what i'm saying).   the whole reason why SE/Linux was
invented was so as to be *able* to do mathematical proofs on the
security of a system (from the underlying FLASK model).  but from what
i know of systemd, i *know* that anyone who does so will be in for a
huge shock.


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

 the NSA's nightmare (or, any intelligence community) is not what you
*know* to be insecure: if you know something's insecure you can put
monitoring, resources or appropriate mitigation strategies in place.
it's what you *don't* know to be secure (or insecure) that's the
nightmare, because you have to assume the absolute worse-case, and
that eats both time and resources.  if they don't *know* then they've
completely failed at their job, basically.

that's fundamentally what SE/Linux was designed for: to be able to
*formally* say, "we know X is secure and Y isn't because here's a
formal mathematical proof of it: X isn't permitted network access, Y
demands waay too many privileges to be secure".  and *now* you can do
a proper risk assessment.

 if systemd is so bloated and all-encompassing that it in effect
demands *all* privileges (it doesn't, but you know what i mean), it
utterly defeats the object of having the security system in the first
place.

or, more to the point: a program which demands such extreme privileges
*is* by definition completely untrustable.  a bit like those android
apps that demand "full access", basically.  you *know* it's going to
be downhill from that point onwards.

l.