On Wed, Feb 15, 2017 at 10:25 PM, zap zapper@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.