Beyond #Grsecurity: The Future of Linux security is Brighter than Ever

Originally published at: News - Whonix Forum

Those of us following security news have heard about grsec’s decision by now.

If you are a current grsec sponsor reading this who doesn’t like their de-facto violation of kernel code licensing, I urge you to privately leak updated versions to Kees Cook (keescook@chromium.org) who can study and incorporate the code into mainline without endangering your access. This will free changes back to the community where they belong and in the long-term you won’t be forced to pay through the nose to run a secure kernel.

PaXTeam is making a false equivalency between their hostile actions and RedHat licensing. To be clear, the GPL does not restrict monetizing software. However businesses can still make handsome profits working around the license by providing support services. RedHat releases back source code - though not in the neat broken up patch-sets but they still release it which satisfies the GPL requirements. Grsec is creating a derivative work of GPL’d kernel code and then coercing customers to relinquish their freedoms.

Reminder: if it wasn’t for the GPL they wouldn’t have a codebase to secure in the first place. if they hate copy-left for being too permissive then they can feel free to fork a BSD kernel and copyright the hardened copy they make.

I think most can agree about where those GPL violators should stick their baton but I think there is a good side to all this. Its a painful reminder that unless code is mainlined and project’s contributions are up-streamed its only a matter of time before they disappear and the code is lost.

No doubt this will catalyze KSPP and bring more security to everyone instead of a select few who know how to tweak and compile a kernel. Another side effect is that protections will be rolled out for many more archs than with grsec support only covering x86 and x64.

Its worth reading Kees Cook’s (KSPP project leader) statement answering common accusations made by Spender and PaXTeam and parroted by their supporters who blame everyone else except their idols who stabbed them in the back.

Unlike the biased comparison on the grsec site, it seems KSPP has successfully integrated more features than they were credited. Much work still remains to be done but its definitely a good start. Its becoming clear that the real reason they closed their sources is in a desperate attempt to not become obsolete.

The Gentoo devs feel particularly betrayed after dedicating lots of effort modifying their userland code to be compatible with PaX and being left out in the cold without warning.

This spawned the Hardened Kernel Project an emerging multi-distro (Gentoo, Arch and hopefully Debian) effort to help upstream as much code as possible. If you write kernel code this project can really use your help.

3 Likes

whats you’re response to this though kernel-hardening - Re: It looks like there will be no more public versions of PaX and Grsec.

Ah the “no one is compensating us” fallacy:

  • PaXTeam wants to get paid for work he never applied for. The way the normal world works is you apply to a company for a job position and they chose to hire you. What most companies don’t do is chase after you to shower you with money.

  • Someone’s a bitter hypocrite. He seems to desperately want the money of the Linux Foundation who he’s been shitting on and criticizing for years.

  • If he can’t get a job for over a decade when he writes such complex software, then maybe he should take a hard, long look why. Its anybody’s guess but my money is on his asshole attitude making him a non-viable candidate. No one wants to hire autistic manchildren who can’t work in a team.

  • If he doesn’t think the copyleft license is good enough, he has other options. No one is forcing him to invest time hacking on a code base that anybody else can use with the requirement that changes are given back.

  • The most likely conclusion: PaXTeam is not really interested in getting a job with Google. He wants to create a strawman justifying the their latest douchebagery. Why should he get paid to upstream stuff once when he can keep making money in perpetuity off the subscription model?

  • Intel doesn’t wanna pay me REEEEE. Before closing their patches Spender attempted to twist Intel’s arm to pay him support fees. So he started a bogus trademark suit against a mega-coproration, what could possibly go wrong? (Bogus because Intel never modified grsec extensively to warrant a name change).

  • Before that they did the “we aren’t getting enough donations so we’re closing down” routine. Twice. In 2004 End Of Development For Grsecurity Announced? - Slashdot and 2009 Re: Grsecurity is about to be discontinued... [LWN.net] There were many earlier signs that things would end this way. I’m surprised it took that long.

Let’s move unto the next part, his technical gobbledygook criticism of KSPP:

  • Understanding people’s code is very hard. So hard that people prefer to rewrite their own alternatives from scratch. If KSPP is struggling to understand a few things in a massive undocumented patch - that’s not their fault. I think they would have been better off not basing off grsec at all.

  • You should take what PaXTeam says at face value. Sometimes there are differing opinions on the best way to technically implement things. You would understand this if you read the mail list and see how patches are constantly revised. He also self-contradicts:
    kernel-hardening - Re: [PATCH v4 2/2] x86/refcount: Implement fast refcount overflow protection

  • Still using the opportunity to differentiate his codebase - that no one can see or use when now everybody stopped giving a shit and moved on.

  • There are plenty of other competent people working to improve KSPP now. This time kernel security will improve without being hostage to the tantrums of two assholes : kernel-hardening - Re: It looks like there will be no more public versions of PaX and Grsec.

Edit by Patrick:
added Intel links as requested by HulaHoop

1 Like

I always thought Paxteam was always more then just one person,so its just one guy?

“I think they would have been better off not basing off grsec at all.”

if they don’t base it off grsec then what should they base it off?I always have thought as Gresecurity/pax being one of the most revolutionary changes in security,and one of the best.

“PaXTeam wants to get paid for work he never applied for”

to my understanding he applied in the open source community where the code and work time is all freely given the only possible money you can get off of it is through donations.Am I right? But If he wanted to,doesn’t he have the right to make it fully commercial since its his coding?or does it have to stay open source forever?

Yes he goes by the name Pipacs too

Perhaps a clean-room implementation but the upstreaming work seems to be picking up.

Source? The open source community is not a company. Its a group of cooperative developers. Some companies sponsor this group under the Linux Foundation but do not have a say in how the kernel is developed. This is based on meritocracy and coding standards enforced by lead devs with git access like Linus.

FYI Spender repeated many times that they are not interested in taking the time upstream their patchset, paid or not.

It seems you haven’t read my original post where I talk about this.

Quiet shocking that only one man created pax he must be a genius.

“It seems you haven’t read my original post where I talk about this.”

“To be clear, the GPL does not restrict monetizing software.”

I did read both posts my comprehension skills just aren’t the best. Ah yes now I found it. Thats interesting didn’t know the GNU license allowed that.

Also are you saying Gresecurity/pax does not satisfies the GPL requirements?

“Grsec is creating a derivative work of GPL’d kernel code and then coercing customers to relinquish their freedoms.”

Are you talking about the Linux kernel?I never heard of the GPL’d kernel code.And how are they coercing customers ?is pax team or spender threatening them?Not sure how their freedoms are relinquished either,they can choose to buy it or not to choose.Can you explain more?

“if it wasn’t for the GPL they wouldn’t have a codebase to secure in the first place.”

If I understand right you’re talking about the GNU licensed Linux kernel,that Gresecurity/pax based off,since the Linux Kernel needed major security enhancements?

“if they hate copy-left for being too permissive then they can feel free to fork a BSD kernel and copyright the hardened copy they make.”

I’m sorry I don’t really understand much,to my understanding you are giving them a possible solution to where they can put gresecurity/pax on a BSD kernel they personally modified for use and make that copyright protected so others would not copy their new product?

"I think most can agree about where those GPL violators should stick their baton "

At themselves I believe is what you’re implying?

“Its a painful reminder that unless code is mainlined and project’s contributions are up-streamed its only a matter of time before they disappear and the code is lost.”

I have heard the term up streaming many times its where to my understanding a project is open sourced and people (community) can review any possible errors or exploits and show their findings to the developer team and suggest a patch to them?An example would be Mozilla firefox or Tor to my understandings

That’s OK :slight_smile: We can go through it one more time.

Yes. They add restrictions that conflict directly with freedoms in the GPL.

Linux is released under the GPLv2. Grsec extensively patches that code and cannot exist on its own making it a derivative work of the Linux kernel.

They threaten to terminate their access to the patches if they distribute the copylefted code to anyone else - violating the GPL’s freedoms that protect that right.

The GPL is absolutely essential to Linux’s success because it kept changes to the codebase free for everyone to use. This allowed several competing companies to contribute to the same project without the threat of someone benefiting and not giving back.

Yes. BSD is permissively licensed meaning legally anyone can take their code and release it under a proprietary license like Apple, Sony and Juniper does. Since hardly anyone gives back to the BSD projects (becuase they don’t have to) they ended up irrelevant with very poor hardware support and a small dev community on Apple’s payroll.

Hmm comeon now…

Not “at” but “in”. You must be scratching your head in utter confusion now. “In” where? you say. In their asses. What the hell is that!? you say. Wikipedia has a wonderful introductory article on the subject with pictures to help explain better than their entire wall of text does.

In the English language its an expression.

Upstreaming means giving back improvements to the original project whose code you used. What you’re talking about is “code review” one of the benefits of contributing your changes to the project.

“They threaten to terminate their access to the patches if they distribute the copylefted code to anyone else - violating the GPL’s freedoms that protect that right.”

Interesting,are there any consequences,for these actions?Such as them having to go to court or something?

I also forgot to ask but when you said

“So he started a bogus trademark suit against a mega-coproration, what could possibly go wrong? (Bogus because Intel never modified grsec extensively to warrant a name change).”

were you refering to when pax said this

“all was well until a few years ago when we learned of several
blatant copyright violations (not of just our code but by extension
that of the upstream kernel too) and also trademark violations.
pursuing these wasn’t too successful and in order to prevent
further abuse we decided to stop the public distribution of
our stable patches and provide it as an entirely commercial
product from then on (all still under the GPL, despite much
speculation to the contrary).”

And whats you’re input on this?

“so what do we have so far about this KSPP business? Google and
other companies made a decision to get our work upstream using
their own resources only - so far so good, it’s their business
in every sense of the word. not involving us however turned out to
be an unwise decision when they realized that their employees are
completely unprepared for this work (we’ll discuss some examples
later). this then led to all kinds of social engineering attempts
at trying to get us to help them out - all without getting paid
for our time, as if we were just supposed to drop all other work
and spend our free time on fixing their botched up attempts. as
if this still wasn’t disgusting and outragous enough, they went
on the combative and had the guts to accuse us of not wanting
to cooperate without also mentioning that they expected all this
work from us for free taken away from our free time.”

Yes. You’d have to be a customer.

Yes.

I have nothing more to add than the comments in this post:

Welp,thanks for the feed backs.

You’re an interesting young fellow with lots of input If your ever free feel free to message me at xoplasma@gmail.com would love to talk to you some more

1 Like

forward port of the last publicly available grsec version:

Unfortunately seems inactive.

1 Like

I wouldn’t recommend using random forward ports without verifying all the code yourself. Although the minipli repo is used by Subgraph and may be trustworthy.

There is also the last public patch available here which you can verify with GPG grsecurity-patches/grsec-4.9 at master · linux-scraping/grsecurity-patches · GitHub

1 Like