Grsec/PAX just went full Jew. What do?

Don't use it

File: considerthis.jpg (24KB, 561x424px) Image search: [Google]

24KB, 561x424px

>>60135754
Fork Grsec/PAX

>>60135754
SELinux or go with Free/Open BSD.

>>60135868
Kernel security is just like an arms race. There have been forks iirc and they're not as fast as implementing features as grsec is.

And it doesn't help that anybody who gives the source code out is immediately cut off from new versions of software by grsec.

>>60136001
>they're not as fast as implementing features as grsec is
*until they went full jew

>>60135754
Whats to stop someone with the full Good Goy Tier Support Contract from distributing the software like the GPL says they can, and then just not tell people who they are, so they don't know whose contract to cancel?

>>60135754
reminder that intel caused this https://twitter.com/ioerror/status/636677916365996032

>>60136001
I was using Arch/GRSec kernel and I moved to OpenBSD when I read the news. So far everything is fine and dandy, I just miss the network-manager applet but the OpenBSD tools are quite fantastic.

If people are concerned with not having the ability to run a grsec kernel, fire up a VM and try one of the BSD's to see if you enjoy them.

>>60135754
>just
What did they do?

>>60136001
OpenBSD's Pledge and FreeBSD's jails are infinitely better than SELinux, MAC's are quite a poor security feature.

File: 04290509.png (20KB, 648x195px) Image search: [Google]

20KB, 648x195px

>>60135754
https://forums.gentoo.org/viewtopic-t-1028036.html
an intersting read that puts some light about the whole issue...
this is confirming my fears about linux going more and more mainstream: funds and credits going the wrong way, doubtful useful software being pushed down the throat by almost all distros (systemd), caring less and less about security

https://news.ycombinator.com/item?id=14229073

https://hardenedlinux.github.io/announcement/2017/04/29/hardenedlinux-statement2.html
We are a group of free software enthusiasts, anarchists, cyber security researchers.
PaX/Grsecurity no longer provides the public access to test patch in Apr 26 2017
As some people already know, it’s not the whole story. As the result of a discussion inside h4rdenedzer0, we believe that Linux foundation is the culprit behind all this result that the commercial/individual/community users losing access to the test patches.

https://grsecurity.net/passing_the_baton.php
This makes grsecurity for Linux 4.9 the last version Open Source Security Inc. will release to non-subscribers.

https://lwn.net/Articles/720983/
No more grsecurity test patches


https://www.spinics.net/lists/arch-general/msg43561.html
End of official PaX and grsecurity support in Arch Linux
The PaX and grsecurity patches are no longer going to be public, so official support in Arch Linux has ended
There are no viable alternatives to PaX and grsecurity. Their focus is on kernel self-protection i.e. protecting the kernel from exploits, and we don't have anything for users to migrate to from these. There are plenty of alternatives to grsecurity RBAC but that's only a small portion of what the patches provide. Any form of access control (whether it's MAC, containers, uid/gid separation, ACLs, etc.) can be entirely bypassed with a single kernel exploit, so the only good way to use other MAC implementations like TOMOYO, AppArmor or SELinux was with grsecurity.

just pay 4 it kekmao

>>60137321
(((free))) software. lel shitnux.

https://www.spinics.net/lists/arch-general/msg43565.html
It's primarily not a technical issue, it's a political ones.
Lots has been outright rejected. Software implementations of SMEP and SMAP are not happening for i386 and x86_64. Proper slab sanitization was rejected. Proper page sanitization was rejected. RAP and SIZE_OVERFLOW upstream are pipe dreams. The REFCOUNT mitigation was rejected and is going to need to be done as opt-in, but they also blocked an efficient implementation like PaX and opt-in usage was rejected in the network stack, etc. It has to be submitted bit by
bit to different maintainers... and that's only the tip of the iceberg for these mitigations.
It's realistically going to take 5+ years for KSPP to land everything other than RAP and SIZE_OVERFLOW and that's assuming it's extremely successful and the political issues are overcome. UDEREF/KERNEXEC will never land in their entirety and PaX and grsecurity are quickly moving targets.
won't have public code to copy... and neither will all of the other new stuff. No one else is doing compelling new kernel security research... so what happens once there's no longer public code to copy? It's literally a copy-paste job right now with bikeshedding of naming and kernel politics, and yet it's still going poorly.

> I mean some grsec users might consider fleeing to HardenedBSD. jails, capsicum, zfs, dtrace, ports and hardenedbsd may have already looked enticing.
HardenedBSD doesn't provide most of the grsecurity mitigations, including some of the most important / strongest mitigations like RAP.

http://planet.debian.org/
Spengler (spender) and the Pax Team recently announced that the grsecurity test patches won't be released publicly anymore. The stable patches were already restricted to enterprise, paying customers, this is now also the case for the test patches.
Obviously that means the end of the current situation in Debian since I used those test patches for the linux-grsec packages, but I'm not exactly sure what comes next

https://news.ycombinator.com/item?id=14202421
https://www.reddit.com/r/linux/comments/67nbqj/grsecurity_passing_the_baton/