On Tue, Feb 27, 2018 at 05:52:22PM +0100, Vincent Bernat wrote: > >> Tim Duesterhus (2): > >> MINOR: systemd: Add SystemD's Protect*= options to the unit file > >> MINOR: systemd: Add SystemD's SystemCallFilter option to the unit file > > > > I took a look, but my systemd incompetence limited my ability to understand > > what this really does. How does systemd act to do this exactly ? I'm very > > worried that the only way it could proceed would be by running the process > > under ptrace causing a tremendous slowdown, and additionally making the > > process unobservable/undebuggable. Do you know how it proceeds > > internally ? > > It uses seccomp.
Ah OK, so we can expect more or less the same level of slowdown as the meltdown workarounds approximately. Not huge but not negligible either. I tend to agree with Pavlos that such config options should not be placed by default. They will definitely break some setups in an unusual way. For example, those using external checks will see their external commands fail (or randomly fail, which is worse). Regarding the access restriction on /home and /root, it turns out that I've met at least one of each in field (the config files and binaries were placed there). Also it would seem quite plausible that some maps or ACLs could be loaded from such locations. In fact, since by default haproxy is supposed to chroot to an empty directory and drop privileges to an unused user, the remaining possibilities for an attacker are much narrower than what can be achieved by only restricting certain classes of syscalls. I think it could make sense to add such lines as a comment to the existing files so that they serve as illustration of what can be done for users who want to go further. Or maybe this is already well-known from systemd users, I don't know. Cheers, Willy
