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

[debrouxl]

At the time of this writing, https://github.com/edera-dev/linux-openpax/branches shows:
* v6.10.x-openpax branch: no update since September 13th, 2024;
* v6.11.x-openpax and master branches: no update since October 31st, 2024, i.e. less than 2 days after this announcement;
* no branch for 6.12.x kernels. 6.12 was released on November 17th, 2024, i.e. more than 3 weeks ago.

Also, there's a total of two issues (one closed) and zero pull requests on that repo.

[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/).

[xhustler]

This invokes memories of Hardened Linux From Scratch.

[baka0815]

Anybody else thought of penny arcade expo (PAX)?

[debrouxl]

PaX is still awesome, as are backported bugfixes but the extra grsec features are rapidly becoming obsolete. Brad picked the best possible time to help commercialise PaX.

chroot isn't secure, never has been and never will be (macOS blocks it outright in favour of sandboxing, FreeBSD replaced it with jails, Solaris with zones) but Linux now provides a superior and more flexible alternative in the form of combining namespaces and capability restrictions with seccomp-bpf, with systemd unit files making mitigations much easier to apply in server scenarios. The RBAC solution is out of place on heavily containerised hosts; Linux now has ways to drop dangerous capabilities from user sessions permanently while still allowing other daemons to do what needs to be done.

grsec's chroot restrictions are indeed not intended to make chroots airtight on their own, and seccomp mode 2 + namespaces are definitely useful, but grsec chroot protections still make Linux chroots functionally closer to FreeBSD jails, by blocking various operations which can help breaking out of chroots. Plymouth is even incompatible with some of these restrictions (see Kconfig help text).
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.

This is a requirement for OpenBSD and iOS / macOS on Arm. This was fixed 9 years ago with SpiderMonkey.

Indeed, the JS JIT is one piece of a browser engine, but there are others
All of the main browser top-level executables were incompatible with MPROTECT before 2017 (public PaX/grsecurity versions), before 2018 (pre-Meltdown unofficial PaX/grsecurity forward ports), and some '2021 commercial patch versions which were published later - I tested the latter by myself a while ago. FWIW, I've also just checked that the main browsers remain in the latest version of paxctld's config file straight up from upstream ( https://grsecurity.net/download ), which contains entries for e.g. python3.13, so it seems almost like a given that current, maintained versions of Firefox and Chrome can't deal with MPROTECT.

I've never heard of grsecurity being used on desktop machines

I did it for years on both personal and work computers, sometimes with significant uptimes, until the unofficial grsecurity forward port went unmaintained after KPTI. More recently, I've test-driven some '2021 commercial patch versions which can be downloaded on the public Internet. Besides a handful of well-known offender applications, which can easily be taken care of by e.g. paxctld, especially Web browsers, a majority of applications work flawlessly out of the box, IME.
There was a performance hit, but it wasn't very noticeable on my Skylake and Coffee Lake laptops, on which PaX/grsecurity takes advantage of hardware PCID+SMAP capabilities to lower the cost and/or strengthen the protection.
In 2016-2017, a growing number of distros was providing grsec kernels.

but like the idea of being able to drop in something like grsecurity if its convenient enough.

MPROTECT is probably one of the most user-visible parts of PaX/grsecurity, because Web browsers crash during startup when it's globally enabled and the xattrs weren't set on the binaries manually or by paxctld, but there are far more parts in even PaX, which will never be integrated to mainline.

[Espionage724]

I've never heard of grsecurity being used on desktop machines

Back early on when I used Arch I used grsecurity for a bit (I think a full kernel?). I didn't want to set-up a MAC like SELinux manually, and grsecurity was easy drop-in and a few kernel options

I'm curious to see where this goes! I'm fine with Fedora and SELinux nowadays, but like the idea of being able to drop in something like grsecurity if its convenient enough.

Edit: Might have been PaX as that sounds familiar too

[mobadboy]

On the one hand, having more users use MPROTECT out of the box for most programs isn't a bad thing for security... even though some of the most exposed programs with the largest attack surfaces, primarily all of the main Web browser engines, can't work without RWX memory at the moment.

On the other hand, PaX does so much more than this - as can be seen in the 4 years of grsecurity patches from 2017-2021 which can be publicly downloaded under the GPLv2, most of the 10+ MB these patches have reached come from the PaX side - that this isn't funny...
Technically, Protection against eXploitation provides, well, efficient defenses against exploitation, multiple of which tended to foil published Linux kernel exploits (I used to play that game back in the day with spender in the LWN comments), missing from both mainline and this OpenPaX thing. The main ones are:
* KERNEXEC: x86 SMEP / ARM PXN / etc. also for processors which don't have these features;
* MEMORY_UDEREF: x86 SMAP / ARM PAN / etc. for processors which don't have these features, and more;
* much more widespread CONSTIFY, part of which is performed partially through a GCC plugin;
* opt-out REFCOUNT protecting all atomics but the ones explicitly unprotected, instead of slowly protecting some refcounts;
* RAP: efficient three-way CFI with both forward edge and backward edge, and more GCC plugins;
* RESPECTRE: GCC plugin for automated Spectre defenses, instead of manual annotations;
* AUTOSLAB (again, GCC plugins, because that is a very good thing) for separated slab caches => reduced reliability of some memory spreading attacks;
* back in the day, safer eBPF JIT code generation, I don't know whether mainline did all about that.
The commercial versions have more than that, e.g. whatever their "KERNSEAL" does, or maybe an improved RANDSTRUCT (GCC plugin, again). While mainline phases out GCC plugins because they can't maintain them, Open Source Security Inc. doubles down on them, which enables them to support a wide range of GCC versions (instead of crippling kernel builds if the compiler isn't very recent) while improving maintainability and code generation. Years ago, I remember that they tried to work with LLVM plugins, but there were technical limitations. Not that LLVM plugins - even if they made it possible to do the job - would help the vast majority of Linux distro users, since pretty few Linux distros don't use GCC to build their kernels and user-space anyway, so it makes perfect sense to work on GCC plugins.

grsecurity adds to PaX e.g. chroot protections, a RBAC, etc. Oh, and security backports which were missed in mainline.

So let's see how this evolves, whether it fares better than linux-hardened, and whether other distros start providing such kernels as well. However, as it stands, AFAICT, it doesn't raise the bar much for attackers... and it won't without all of KERNEXEC (many people still use Sandy Bridge or older Intel Processors, or AMD Zen processors without SMEP - IIRC, pre-Zen), MEMORY_UDEREF (even more people still don't use Broadwell/Skylake/Zen processors), wide CONSTIFY, proper REFCOUNT, RAP and possibly AUTOSLAB.

I've never heard of grsecurity being used on desktop machines

[brad0]

primarily all of the main Web browser engines, can't work without RWX memory at the moment.

This is a requirement for OpenBSD and iOS / macOS on Arm. This was fixed 9 years ago with SpiderMonkey.

[ssokolow]

I suppose that it's possible to generate code into pages in w or rw mode, then switch the permissions on these pages to rx when the generation is over... but of course, for performance reasons, everybody takes the rwx-assuming code + rwx permission shortcut.

I thought I read an article a few years ago about how at least one JavaScript JIT had started to work toward the "then switch" mode of operation, reinforcing my assumption that it wasn't a matter of performance, but one of "which mode of operation takes more work to implement when you have a pre-W^X codebase already functioning?"

[Martyn]

grsecurity adds to PaX e.g. chroot protections, a RBAC, etc. Oh, and security backports which were missed in mainline.

PaX is still awesome, as are backported bugfixes but the extra grsec features are rapidly becoming obsolete. Brad picked the best possible time to help commercialise PaX.

chroot isn't secure, never has been and never will be (macOS blocks it outright in favour of sandboxing, FreeBSD replaced it with jails, Solaris with zones) but Linux now provides a superior and more flexible alternative in the form of combining namespaces and capability restrictions with seccomp-bpf, with systemd unit files making mitigations much easier to apply in server scenarios. The RBAC solution is out of place on heavily containerised hosts; Linux now has ways to drop dangerous capabilities from user sessions permanently while still allowing other daemons to do what needs to be done.