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.