Quoting Russell Coker (russell@coker.com.au):

> Why not have a $100 bet about your ability to perform the type of
> compromise that you think is the big problem?

Was it you or some _other_ Russell Coker who claimed that the issue I
actually _did_ describe -- which you then misrepresented -- was a 'minor
issue compared to web browsers, MUAs, and other programs which directly
and predictably accept data from potentially hostile sources'?

Because, I call bollocks, sir.  And I gather that you refuse to put your
money where your mouth is.


Now, as to _a_ security problems caused by calls from systemd to other badly
written Freedesktop.org software, I can give you a particular type of
example immediately, as it is well known, albeit it is not a root
compromise or anything quite like that:  My friend Jim Dennis, who was a
co-worker at Linuxcare in 1999 when he co-wrote a book on Linux system
administration
(http://www.amazon.ca/Linux-System-Administration-M-Carling/dp/1562059343)
has a saying that 'Security is the implementation of policy.'  By a
functional definition, if a system runs the processes of authorised
users and not those of unauthorised ones, that is good security.

In typical current systemd-based GNOME systems[1], including recent Arch
Linux ones, systemd intercepts and refuses the superuser's directive to
shutdown or reboot the system if a Freedesktop.org codebase called
PackageKit, to which systemd communicates over D-Bus (as it does with a
thundering herd of other Freesdesktop.org plumbing) unilaterally decides
that shutdown/reboot ought to be non-negotiably deferred because package
operations are underway.

Now, it's doubtless possible to disable that behaviour one way or
another, but the point is that this behaviour, considered normal with
systemd and the Freedesktop.org suite it continally communicates with,
overrides the judgement of the superuser to shut down.  In my book, the
only thing that ought to be more definitive than the root user wielding
the /sbin/shutdown utility is the root user yanking the mains cord.  The
superuser needs to be able to shut down NOT and know that it will
happen, for any of a number of reasons.


Beyond that, if you actually choose to believe that systemd and
ancillary code (including without limitation all the Freedesktop.org
stuff it chatters with all the time over D-Bus) doesn't have
a vastly greater attack surface than other modern inits, I will regard
that position as self-parodying and don't think I need to demonstrate
anything.


[1] Judging by a recent post in this space, this seems perhaps no longer
likely to happen on Debian Jessie, which would be a step forward.

_______________________________________________
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main