OpenPaX Announced As "Open-Source Alternative To GrSecurity" With Free Kernel Patch

[gotar]

However, most systemd unit files do not apply namespace or seccomp mode 2 mitigations, according to the output of `systemd-analyze security` on various server and desktop machines I have access to, even recent ones (Debian sid amd64). UNSAFE (red color) services represent a crushing majority in there, with 9.6 and 9.5 exposure scores being the most common. There's a sprinkling of EXPOSED (yellow) for services whose exposure score is slightly lower than 9.0, and the remainder of OK (green) is a small minority.

The point is - one can easily put hardening drop-ins on service-per-service basis, according to his own risk assessment.

For example, I run PHP-FPM pools (one per webapp) as templated services, each using their own user/group (including the master process) and various Protect*/Restrict* flags and resource limits, used by separated Apache proxy workers using different user/group (socket/logs permissions granted in ExecStartPre= using fACLs), to host services from noexec mountpoints (including tmpfses), all of that running from within userns-disabled and further restricted container nspawned itself in user namespace from bare-metal host.
This includes no_new_privs and bounded capabilities.

Ability to reduce attack surface coarsely for network-facing code is crucial and only systemd enabled it for widespread use. These are real gains, much more effective than open basedir (disabling realpath cache) and protect against real, not theoretical threats.

This of course isn't bulletproof and there might be dozens of escape or exploitation methods I am not aware of, including future and newly discovered bugs, but each and every layer of protections can stop or slow down at least scripted attacks and ease system management or defense - e.g. I can stop or further restrict single PHP application that's under attack beyond that what's possible with PHP pools (like disabled_functions).

I'm not saying that PaX-addressed issues are irrelevant, but during the last years multiple security mechanisms were introduced or made available for everyone, so missing one layer is not as big problem, as it was before. Back then you had to worry about protecting from possibly malicious code, now you protect against running unknown code at all and if that's not tight enough - against escalating. As the chain of exploitation grows, the overall security improves. Today attacker needs several unpatched and not mitigated CVEs at once to succeed.

As an example, having full system access sometimes I need to relax some of the restrictions temporarily just to do some task in situ. It's easy thanks to

systemctl set-property --runtime

and it's worth noting, that accounting for lazy admin is also part of the security. The restrictions put in place must not interfere with regular service maintenance and be auditable (i.e. drop-in comments, runtime properties living in /run/systemd/system.control/).