Originally posted by debrouxl
View Post
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
Code:
systemctl set-property --runtime
Comment