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

[phoronix]

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

Enterprise security firm Edera today is announcing OpenPaX that they promoted in their advance press notice as a "new open-source alternative to GrSecurity." GrSecurity being the firm focused on providing out-of-tree Linux kernel patches focused in the name of security enhancements. With OpenPaX they are open-source and publicly available kernel patch for mitigating common memory safety errors and other system hardening...

https://www.phoronix.com/news/Edera-OpenPaX-Announced

[Beryesa]

Smells like a future CrowdStrike accident

[debrouxl]

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.

[stormcrow]

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

Pretty sure that's a consequence of JIT behavior in general. IIRC, all systems using a JIT compiler on OpenBSD requires setting special exceptions to let them run as the kernel will enforce write/executable separations by default thus blocking the on-the-fly-write -> execution path. Pretty sure there's no way around this unless one just doesn't use JIT (which means no software system that requires it will run, not just browsers either but Java virtual machines, some database engines, etc).

[szymon_g]

I wasn't aware grsecurity was still a thing tbh

[avis]

Michael

Would be nice if you compared the performance of this security enhanced kernel to the mainline one.

Security almost never comes for free.

[debrouxl]

Pretty sure that's a consequence of JIT behavior in general. IIRC, all systems using a JIT compiler on OpenBSD requires setting special exceptions to let them run as the kernel will enforce write/executable separations by default thus blocking the on-the-fly-write -> execution path. Pretty sure there's no way around this unless one just doesn't use JIT (which means no software system that requires it will run, not just browsers either but Java virtual machines, some database engines, etc).

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 wasn't aware grsecurity was still a thing tbh

They're even going much stronger since the latest version of the patches was switched to be accessible only on a commercial basis (but still under the conditions of the GPLv2, needless to say)... They've been able to start living off their work, recruit more people (at least Matthias "minipli" Krause), write brand-new defenses (RESPECTRE, KERNSEAL, AUTOSLAB, probably others), provide internships to younger security researchers, contribute money to projects useful to the general ecosystem (especially funding the GCC Rust efforts: they're one of the very few entities to do that), etc.

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 ?

[debrouxl]

Michael

Would be nice if you compared the performance of this security enhanced kernel to the mainline one.

Security almost never comes for free.

In the current state of OpenPaX, i.e. basically only MPROTECT + EMUTRAMP + better ASLR (hey, PaX invented the latterover 20 years ago), it should be hard to measure a difference. Programs which can't deal with MPROTECT typically outright crash anyway, instead of switching to a reduced performance mode.
On a PCID-less x86-64 processor, KERNEXEC + MEMORY_UDEREF have measurable cost, though... like mainline's narrower KPTI, anyway. I remember reading a post by PaXTeam about PaX using PCID for stronger/faster MEMORY_UDEREF, a while before mainline starting to do so as a way to reduce the cost of Meltdown mitigations. Easily verifiable in PaX/grsecurity patchsets before 2018 anyway.
On 32-bit x86, ISTR that KERNEXEC + MEMORY_UDEREF aren't bad, thanks to segmentation.

[Daktyl198]

Why haven't any of these patches been in the kernel before? Custom patches to GPL code has to be GPL as well, right?

[debrouxl]

Why haven't any of these patches been in the kernel before?

Nobody sufficiently motivated, and with enough time (and therefore money) on their hands, to go through the full process of the integration of even a very narrow set of features (MPROTECT, EMUTRAMP, changes to ASLR)... assuming they're even desired upstream in the first place, which remains to be seen.

Custom patches to GPL code has to be GPL as well, right?

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.