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

[intelfx]

They switched to commercial because having to fix the bugs in the mainline integration (by the kernel hardening project) of watered-down forks of outdated versions of their GCC plugins, while being largely unpaid (donation-only), was unsustainable. Everybody losing direct access to the latest version of the PaX & grsecurity patches because of the mainline kernel hardening effort, which has never integrated (in 7 years and a half, by now) any of the major defenses in their full capacity... does the limited good really offset the major bad of the kernel hardening effort ?

They were never obligated to "have to fix the bugs". This entire blurb sounds like an obscene amount of proprietary-washing

The only major bad is on those grsecurity clowns. Nobody cares though. I guess they can continue to sell their expensive snake oil.

[Emmanuel Deloget]

That they are, indeed, be it the grsecurity patches, or the Red Hat patches, for instance.
The 2017-2021 commercial grsecurity patches which have been published on the open Internet are under the GPLv2, just as the pre-commercial patches were.

And for more information on the subject : https://grsecurity.net/faq

The GPLv2 means that once you get the patch, you are allowed to redistribute it (you can also ask money to do so). The license itslef never required this distribution to be free as in beer (hence the commercial nature of this patchset in the first place).

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

[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?"

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

[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

[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

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

[baka0815]

Anybody else thought of penny arcade expo (PAX)?

[xhustler]

This invokes memories of Hardened Linux From Scratch.