|SUBJECT ||Subject: [Hangout-NYLXS] systemd critique et al
|From hangout-bounces-at-nylxs.com Mon Dec 19 06:42:02 2016
Received: from www.mrbrklyn.com (www.mrbrklyn.com [126.96.36.199])
by mrbrklyn.com (Postfix) with ESMTP id 38D79161317;
Mon, 19 Dec 2016 06:42:01 -0500 (EST)
Received: from linux-p1s6.site (stat20.mrbrklyn.com [10.0.0.26])
by mrbrklyn.com (Postfix) with ESMTP id 880FC161315
for ; Mon, 19 Dec 2016 06:41:58 -0500 (EST)
Date: Mon, 19 Dec 2016 06:41:58 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Subject: [Hangout-NYLXS] systemd critique et al
Reply-To: NYLXS Discussions List
List-Id: NYLXS Discussions List
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Systemd is not Magic Security Dust
maintainer David Strauss has published a response to my blog post about
systemd. The first part of his post is replete with ad hominem
fallacies, strawmen, and factual errors. Ironically, in the same breath
that he attacks me for not understanding the issues around threads and
umasks, he betrays an ignorance of how the very project which he works
on uses threads and umasks. This doesn't deserve a response beyond what
I've called out on Twitter.
In the second part of his blog post, Strauss argues that systemd
improves security by making it easy to apply hardening techniques to the
network services which he calls the "keepers of data attackers want."
According to Strauss, I'm "fighting one of the most powerful tools we
have to harden the front lines against the real attacks we see every
day." Although systemd does make it easy to restrict the privileges of
services, Strauss vastly overstates the value of these features.
The best systemd can offer is whole application sandboxing. You can
start a daemon as a non-root user, in a restricted filesystem namespace,
with mandatory access control. Sandboxing an entire application is an
effective way to run potentially malicious code, since it protects other
applications from the malicious one. This makes sandboxing useful on
smartphones, which need to run many different untrustworthy, single-user
applications. However, since sandboxing a whole application cannot
protect one part of the application from a compromise of a different
part, it is ineffective at securing benign-but-insecure software, which
is the problem faced on servers. Server applications need to service
requests from many different users. If one user is malicious and
exploits a vulnerability in the application, whole application
sandboxing doesn't protect the other users of the service.
For concrete examples, let's consider Apache and Samba, two daemons
which Strauss says would benefit from systemd's features.
follow the link for the rest
hangout mailing list