
Grsecurity: Potential contributory infringement and breach of contract risk - SwellJoe
http://perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/
======
43224gg252
I stopped taking Grsec seriously a long time ago. Grsec makes the kernel more
secure by breaking it. The code in their patches does not meet the
standards/style of the Linux kernel and has in fact been criticized by third
parties for just not being good code. I could make a crappy patch that breaks
networking and market it as a security feature because it "prevents
intrusion", but it also breaks useful features. They appear to have some kind
of internet defense force or something defending them at every turn but it's
become more and more apparent lately that grsec is a low-quality code base
maintained by programmer(s) with bad attitudes and superiority complexes.

I've been in tech for quite some time and never encountered anyone using grsec
patches. They do a really good job of marketing their product on tech forums
though.

~~~
SwellJoe
I see grsecurity in the web hosting industry a _lot_. Tons of people have
bought their snake oil (and major players in the shared hosting and multi-
tenant hosting space are proponents of grsec).

I've always been uncomfortable with it, even though there are a handful of
good ideas in there. Why would I trust something that isn't allowed to go
through the normal quality vetting process as the rest of the kernel?

~~~
muppetman
What about grsecurity do you consider to be snake oil?

A couple of times the grsecurity patch has prevented a machine of mine being
exploited - the first time the exploit didn't work at all and the second
grsecurity added enough protection that the kernel crashed and rebooted.

I consider both Brad and PaX Team to be very clever people (though you could
easily argue I'm biased as I use the grsecurity patch, confirmation bias and
all that)

The fact the kernel protection project are trying to take grsecurity and get
it implemented into the kernel also suggests to me that it's not snake oil.

So I'm curious as to why you think it is?

~~~
sillysaurus3
_A couple of times the grsecurity patch has prevented a machine of mine being
exploited - the first time the exploit didn 't work at all and the second
grsecurity added enough protection that the kernel crashed and rebooted._

Out of curiosity, how did you determine that someone was trying to exploit
you? And that the kernel crash was due to an attack?

~~~
muppetman
Both times friends of mine with shell accounts tried the last kiddy exploit.
First time they fessed up they'd tried it and said it didn't work, the second
time apologised for causing the box to reboot.

~~~
SAI_Peregrinus
Since crashes (especially segfaults) are often indications of an exploitable
vulnerability causing the kernel to crash isn't exactly a good thing. It
prevented one attack, caused a (probably short) denial of service, and may be
further exploitable.

~~~
ryanlol
Grsec doesn't magically make bugs go away, it just makes many of them
unexploitable, or at least very hard to exploit.

------
MilnerRoute
Bruce Perens answered questions today on Slashdot about his position.

[https://linux.slashdot.org/story/17/07/09/188246/bruce-
peren...](https://linux.slashdot.org/story/17/07/09/188246/bruce-perens-warns-
grsecurity-breaches-the-linux-kernels-gpl-license)

"It's important to consider the goals of the GPL," he writes at one point.
"You get great Free Software, but it's not a gift. It is sharing with rules
that must be followed. You are required to keep it Free. And one of the
implied purposes of the GPL is to cause more great Free Software to be made.
This means that derivative works that are not shared really go against the
purpose as well as the wording of the GPL."

------
simcop2387
I've got a question about this whole GPL enforcement issue.

Scenario:

I'm a VPS company, I provide my customers with kernels compiled with GRSec. I
provide a number of modules for different protocols, nftables, etc. with the
custom kernels i've built for the VMs. Under the GPL I have to provide the
patched source of all those modules (and kernel If I provide that image too)
to my customer.

Question:

With GRSec's reported threat of no longer being allowed to be a customer of
theirs if I provide the legally required source to my customer, does this mean
I can no longer reconcile their two licenses and means that I cannot use their
kernel patches for my customers?

~~~
SwellJoe
That's a big part of the implication of this post, I think.

Grsecurity heavily markets itself to the multi-tenant hosting industry. Thus,
your scenario is a big part of their customer base. So, if these allegations
are true, then not only is grsecurity violating the GPL, they're demanding
their customers violate the GPL, too.

~~~
lokedhs
Shouldn't that be simple to test though? Sign up for one of the hosting
providers that uses them and ask for the source code too their kernel and see
what they reply.

If I were to guess, I think that they'd argue that providing you with an
environment on which you can run your software doesn't equate with
"distribution" under the GPL.

Keep in mind that the cloud issues (and patents) were what caused GPL v3 to be
written in the first place.

~~~
simcop2387
Yea that's why I specifically mentioned modules in my original comment. It
might be possible to argue that you don't get to see the kernel image so it
wasn't distributed to you, but if they gave you modules from that kernel that
you can load/unload then it'd be a lot harder to make that argument that they
weren't distributed to you.

------
mrsteveman1
To date, all of the discussion over what GRsec has done is about distribution
rights, but it appears the GRsec agreement[0] also contains this:

> If the User has received pricing for the stable patches on a specific
> product, use of the patches on additional products without the consent of
> the Company will result in termination of access to future updates of
> grsecurity stable patches and changelogs.

So while the patches are derivative works of the upstream kernel, which is GPL
licensed, they're attempting to restrict the _use_ of the patched kernel
source as well by requiring "consent" to use the combined work, the bulk of
which was not written by the GRsec developers and has been licensed directly
from the upstream kernel authors to anyone who receives it.

That directly contradicts freedom 0: the freedom to run the program as you
wish, for any purpose.

[0]
[https://grsecurity.net/agree/agreement.php](https://grsecurity.net/agree/agreement.php)

[1] [https://www.gnu.org/philosophy/free-
sw.en.html](https://www.gnu.org/philosophy/free-sw.en.html)

------
drewcrawford
> Currently, Grsecurity is a commercial product and is distributed only to
> paying customers. My understanding from several reliable sources is that
> customers are verbally or otherwise warned that if they redistribute the
> Grsecurity patch, as would be their right under the GPL, that they will be
> assessed a penalty: they will no longer be allowed to be customers, and will
> not be granted access to any further versions of Grsecurity. GPL version 2
> section 6 explicitly prohibits the addition of terms such as this
> redistribution prohibition.

This is a fundamental misunderstanding of the GPL. The GPL merely requires
corresponding source to be made available alongside binaries, so if you get a
binary from someone you have a right to the corresponding source from that
person. It does not require anyone to offer you a binary; it merely says if
they did, you can get the corresponding source.

GRSecurity has no obligation to provide you a binary, they can decline to
offer you one because you have a silly walk or a 13-character username or you
exercised your rights under the GPL. The GPL does not entitle you to product
updates or to continue to be a customer of someone who doesn't want you as a
customer, it merely entitles you to corresponding source for binaries.

Some would say GRSecurity's practice violates the spirit of the GPL, but the
GPL is not a spiritual entity, it's a legal document, and if you want a legal
document that produces a different outcome you can write one up.

Also, you should read the fine print from any other Linux vendor – RHEL,
Oracle, etc. You don't have to go on "my understanding from several reliable
sources", the documents actually state they'll terminate you as a customer if
you redistribute their stuff.

~~~
SwellJoe
"Also, you should read the fine print from any other Linux vendor – RHEL,
Oracle, etc. You don't have to go on "my understanding from several reliable
sources", the documents actually state they'll terminate you as a customer if
you redistribute their stuff."

I don't know about Oracle, but I know about Red Hat. They not only do not
prohibit one from distributing source code and the patches they apply to it,
they distribute it freely themselves, and help maintain a free distribution of
RHEL called CentOS built from the same sources they use for RHEL.

There is no reasonable way to compare Red Hat's policies about source
distribution and availability to grsecurity.

~~~
drewcrawford
> Red Hat. They not only do not prohibit one from distributing source code and
> the patches they apply to it

Of course they prohibit it. e.g. from [1]

> This EULA does not permit you to distribute the Programs or their components
> using Red Hat's trademarks, regardless of whether the copy has been
> modified. You may make a commercial redistribution of the Programs only if
> (a) permitted under a separate written agreement with Red Hat authorizing
> such commercial redistribution, or (b) you remove and replace all
> occurrences of Red Hat trademarks.

from [2]

> Distributing the Software and Services (or any portion) to a third party
> outside the Portal or using the Software and/or Services to support a third
> party without paying for each Instance is a material breach of this
> Agreement even though the open source license applicable to individual
> software packages may give you the right to distribute those packages

from [3]

> Any unauthorized use of the Subscription Services is a material breach of
> the Agreement, such as... (d) using Subscription Services in connection with
> any redistribution of Software

[1]
[https://www.redhat.com/f/pdf/licenses/GLOBAL_EULA_RHEL_Engli...](https://www.redhat.com/f/pdf/licenses/GLOBAL_EULA_RHEL_English_20101110.pdf)

[2]
[https://www.redhat.com/licenses/cloud_CSSA/Red_Hat_Cloud_Sof...](https://www.redhat.com/licenses/cloud_CSSA/Red_Hat_Cloud_Software_Subscription_Agreement_for_Microsoft_Azure.pdf)

[3]
[https://www.redhat.com/licenses/GLOBAL_Appendix_one_English_...](https://www.redhat.com/licenses/GLOBAL_Appendix_one_English_20160111.pdf)

~~~
SwellJoe
Your first quote covers trademarks. That is unrelated to source code. CentOS
ships with a different set of trademarks. If you want to rebuild and
redistribute the RH sources, you remove the trademarks. That's well understood
and well within the terms of the GPL.

Second refers to binary builds of the software. Also well within the terms of
the GPL.

Third refers to the Subscription Service which includes access to binary
builds, access to a customer portal with knowledge base, private support
tickets, etc.

None of these refer to distribution of source, which is explicitly permitted
by Red Hat.

~~~
drewcrawford
> Your first quote covers trademarks. That is unrelated to source code.

Source code contains trademarks, that is why CentOS has to remove them. If you
distribute the source code you get from the RHEL subscription area you have
violated your RHEL agreement.

You are not in violation of the GPL, but that is precisely my point: everybody
does this, and nobody (except OP) believes it is a GPL violation.

~~~
SwellJoe
I'm not interested in re-litigating the trademark discussion here. It's not
relevant to the grsecurity conversation, and it's been settled for a decade or
so. Trademark law is separate from copyright law and really has no place in a
copyright discussion.

Red Hat places branding in their own packages, generally, which is easily
replaced by distributions...they do their own re-branding in Fedora and
CentOS; the trademarks are built to be removable. Red Hat went out of their
way to make it easier to build a from-source RHEL without violating
trademarks, despite not really having a legal obligation to do so.

~~~
drewcrawford
My assertion had nothing to do with whether they made it easy or hard to
remove their trademarks.

My assertion was that Red Hat customers make agreements with Red Hat in which
they agree not to redistribute RHEL. That is directly analogous to the
GRSecurity case, except there we are relying on something OP heard thirdhand
and in the case of RH we can read the agreements.

~~~
SwellJoe
"My assertion was that Red Hat customers make agreements with Red Hat in which
they agree not to redistribute RHEL. That is directly analogous to the
GRSecurity case, except there we are relying on something OP heard thirdhand
and in the case of RH we can read the agreements."

Then your assertion is a lie. I feel like I'm talking to a wall.

Red Hat very clearly _does not_ prohibit distribution of the source of their
kernel, or any other GPL component of RHEL, and in fact they make it available
for free in the form of CentOS, and they do not prohibit others from
distributing it either. Everything you've quoted above says nothing about what
you keep saying it means.

------
bhenc
I think it is unfair to attack the grsecurity guys like this. They've been
providing their patches free of charge for years only to have their work
abused.

I mean, this whole situation seems a lot like the one described in the
following articles, and afaik RedHat is still not facing any lawsuits:
[https://lwn.net/Articles/432012/](https://lwn.net/Articles/432012/)
[http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracl...](http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell_with_change_to_source_code_packaging/)

Now RedHat has the benefit that they claim they're "upstream first", but afaik
ASLR originated with the grsecurity guys, so there is grsecurity stuff in the
vanilla kernel. Is ASLR snake oil?

I don't see how the situation is different between how grsecurity did things
and RedHat. Between going out of business and working on the boundary of the
GPL, they chose to stay in business.

More importantly, how would you deal with publishing under the GPL and making
money off of it? This whole discussion reminds me of this article:
[http://widgetsandshit.com/teddziuba/2010/01/i-love-the-
gpl-e...](http://widgetsandshit.com/teddziuba/2010/01/i-love-the-gpl-except-
when-it.html)

The way things are going, the best direction to take if you want to produce
GPL code is to have another job unrelated to programming to earn enough to
code in your free time. It's really sad if you think of the megacorps that are
making billions off of FOSS.

I'll end up with a quote by Steve Jobs: By the way, what have you done that’s
so great? Do you create anything, or just criticize others work and belittle
their motivations? [http://widgetsandshit.com/teddziuba/2010/05/the-future-of-
ap...](http://widgetsandshit.com/teddziuba/2010/05/the-future-of-apples-
curated-computing.html)

------
zzalpha
Edit:

I replied too soon and misunderstood the core of Peren's argument.

His claim is that by withdrawing support if a customer redistributes the
grsecurity patch (which absolutely _is_ licensed under the GPLv2), that
amounts to adding a clause to the GPL due to the penalty this imposes.

At issue is this agreement:

[https://grsecurity.net/agree/agreement.php](https://grsecurity.net/agree/agreement.php)

This clearly represents additional conditions imposed on the software. Seems
like a grey area as to whether those conditions at enough to violate the GPL
under which the Linux kernel is licensed.

Original comment:

I don't buy it.

Grsecurity isn't distributed as a derivative work of the Linux kernel.

Just because it's useless without the kernel doesn't make it a derivative
work. By that logic, Nvidia's closed source driver would qualify as a
derivative work and fall under the GPL.

~~~
DannyBee
"Just because it's useless without the kernel doesn't make it a derivative
work. By that logic, Nvidia's closed source driver would qualify as a
derivative work and fall under the GPL. " FWIW: This is in fact, the belief of
a number of lawyers.

~~~
resf
Nvidia have a lot of money, so the law is on their side.

------
averagewall
Can someone explain how the GPL covers Grsecurity at all? It sounds like it's
entirely their own code they wrote themselves and have all the rights to. It
just happens to be something that their customers are going to use with GPL
Linux. They're not distributing any GPL code are they? I can't believe a
derivative work can include something that is merely compatible with GPL code
but doesn't actually contain any. Or does it? Have they copied and pasted GPL
code into the Grsecurity patch? In that case, then it does make sense that it
should be GPL'd too.

~~~
amluto
If you open an old version of the patch, you'll find that it adds, removes,
and changes lines in the middle of existing Linux functions. If it's not a
derivative work, I don't know what is.

~~~
averagewall
You mean it contains copies of existing Linux functions which the Grsecurity
authors have edited? That makes sense. A lot of the comments here seem to be
about how tightly it interfaces with Linux, which is surely a different thing.

~~~
amluto
This is a little snippet of grsecurity:

    
    
       static void account_kernel_stack(struct task_struct *tsk, int account)
       {
      -       void *stack = task_stack_page(tsk);
              struct vm_struct *vm = task_stack_vm_area(tsk);
       
              BUILD_BUG_ON(IS_ENABLED(CONFIG_VMAP_STACK) && PAGE_SIZE % 1024 != 0);
      @@ -303,8 +357,12 @@ static void account_kernel_stack(struct task_struct *tsk, int account)
                       * All stack pages are in the same zone and belong to the
                       * same memcg.
                       */
      +#ifdef CONFIG_GRKERNSEC_KSTACKOVERFLOW
      +               struct page *first_page = virt_to_page(tsk->lowmem_stack);
      +#else
      +               void *stack = task_stack_page(tsk);
                      struct page *first_page = virt_to_page(stack);
      -
      +#endif
                      mod_zone_page_state(page_zone(first_page), NR_KERNEL_STACK_KB,
                                          THREAD_SIZE / 1024 * account);
    

Grsecurity isn't Linux plus some additional code. It's a modified version of
Linux. Saying that a Linux 4.11 kernel patched with grsecurity isn't a derived
work of Linux 4.11 is like saying that a Linux 4.11 kernel patched with
patch-4.12.patch [1], otherwise known as Linux 4.12, is not a derived work of
4.11

[1]
[https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.12.xz](https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.12.xz)

------
yuhong
I wonder what is the current status of the Wind River debacle.

------
lawnchair_larry
LOL. Please, just bow out on topics related to security. You are spreading
misinformation.

~~~
dang
Personal attacks will get you banned on HN. Surely you know that? Please don't
do this again.

We detached this comment from
[https://news.ycombinator.com/item?id=14732721](https://news.ycombinator.com/item?id=14732721)
and marked it off-topic.

------
vectorEQ
grsecurity is a good effort, if you dont like it dont use it but dont complain
about people trying to make a turd less of a turd even if it is of your
opinion they fail at it. alot of people sell software that 'only functions on
linux', people even sell linux based appliances, they all leave the licence
files etc. neatly tucked away somewhere for licence nazis to find >.>. people
who critisize grsecurity and praise linux probarbly dont care much about the
rootkits in their systems >.>

------
makomk
I'm curious why the same argument wouldn't apply to Red Hat Enterprise Linux
and all its customers, since they apply the same policy of terminating the
license of anyone who redistributes it to their kernel patch set.

~~~
SwellJoe
That's not accurate. Everything Red Hat does is OSS. Their kernel patches are
developed in the open, and available to anyone. The only thing they restrict
is binary distribution.

~~~
yjftsjthsd-h
To belabor the point, it is my understanding that CentOS is literally
identical to RHEL minus a couple identifiers (/etc/issue and the like) and a
license with a support contract. You can even convert it into RHEL by buying a
license and installing a couple packages.

~~~
makomk
CentOS can ship a system that's effectively identical to RHEL because Red Had
publish their patched kernel source. What they don't distribute publicly and
is only available to customers, under penalty of contract termination if they
release it, is the patches that make up their kernel. So non-customers can't
easily tell what they've changed, back out patches that break stuff, or
cherry-pick patches for non-RHEL use. This is obviously nicer than the
gresecuriy approach but there's no obvious reason why it's any more legal.

~~~
protomyth
If what you say is true, and I have no doubts you are correct, then how is Red
Hat's kernel policy different from Grsecurity? They both alter the kernel and
contractually bind the recipient not to distribute the source on pain of
contract termination. I'm not asserting bad / good. I'm would like to know the
difference.

~~~
SwellJoe
"They both alter the kernel and contractually bind the recipient not to
distribute the source on pain of contract termination."

Red Hat does not contractually bind anyone to not distribute source. They just
don't. They distribute the source themselves, without contract or cost.

And, Red Hat employs several of the largest contributors to the mainline Linux
kernel. Most of the time, if something is in the RHEL kernel, there are people
working on pushing it into the mainline kernel either before or after it goes
into the RHEL kernel. Red Hat has consistently and for decades worked _with_
the Linux community to build a better kernel.

I'm not trying to be a Red Hat fanatic or anything, but they've been trotted
out multiple times in this thread as being "just like grsecurity", and it's
just flabbergastingly wrong to compare the two.

~~~
protomyth
Ok, so what is Red Hat contractually binding me not to do? Am I
misunderstanding what makomk is trying to say?

~~~
mobilethrow
While Red Hats individual kernel patches are not available, they distribute
the "squashed" sources under the terms of the GPL.

~~~
protomyth
Thanks for the answer. Is the removal of the context of the changes generally
considered acceptable? We have a Red Hat license, but frankly, I am more a BSD
person and our use of Red Hat is a requirement for specific programs.

~~~
SwellJoe
Yes, it is well-understood to be acceptable. In the past, most commercial
Linux distributions were developed behind closed doors in private revision
control and pushed out as "complete" source packages. We had these
conversations back then (~20 years ago), and the community and the companies
involved came to mostly agree about what is and isn't OK. That's opened up a
lot in recent years, such that these days "open source" usually means, "we
have a public git repository", but it does not have to.

The GPL provides you some basic rights: you can request the source in a usable
form, you can change it, you can redistribute it under the same terms.

It does not require access to the process that produced the software.

These days, Red Hat develops almost everything way out in the open. Contrary
to all of the talk in this thread where folks (mostly just one guy, actually)
keeps implying RH are violating the license or making it hard to get and
distribute source, you can see discussions _and_ the actual code being worked
on months in advance of what will be in RHEL by following Fedora development.
Fedora is developed entirely in public repositories and mailing lists, and it
is where much of RHEL development takes place (RHEL trails Fedora by about 12
to 18 months, in terms of versions, and things that will be in RHEL next year
are in Fedora today). Red Hat is an excellent OSS company who do damned near
everything right, IMHO. Any complaints I might have about some of their
practices (like I said elsewhere, I _liked_ having a kernel SRPM that was the
mainline kernel plus listed patches, and I miss it being that way) pale in
comparison to the good they do for the OSS community.

Just because they make a lot of money doesn't mean they're cheating the
community out of anything.

