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.
Announcement
Collapse
No announcement yet.
OpenPaX Announced As "Open-Source Alternative To GrSecurity" With Free Kernel Patch
Collapse
X
-
Originally posted by debrouxl View PostHowever, 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.
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 toCode:systemctl set-property --runtime
- Likes 1
Leave a comment:
-
Originally posted by Martyn View PostPaX 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.
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.
Originally posted by brad0 View PostThis is a requirement for OpenBSD and iOS / macOS on Arm. This was fixed 9 years ago with SpiderMonkey.
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.
Originally posted by mobadboy View PostI've never heard of grsecurity being used on desktop machines
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.
Originally posted by Espionage724 View Postbut like the idea of being able to drop in something like grsecurity if its convenient enough.
- Likes 2
Leave a comment:
-
Originally posted by mobadboy View Post
I've never heard of grsecurity being used on desktop machines
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 tooLast edited by Espionage724; 31 October 2024, 12:56 AM.
- Likes 1
Leave a comment:
-
Originally posted by debrouxl View PostOn 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.
Leave a comment:
-
Originally posted by debrouxl View PostI 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.
- Likes 1
Leave a comment:
-
Originally posted by debrouxl View Postgrsecurity adds to PaX e.g. chroot protections, a RBAC, etc. Oh, and security backports which were missed in mainline.
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.
- Likes 3
Leave a comment:
Leave a comment: