Live data from Hacker News

Grsecurity: Potential contributory infringement and breach of contract risk

perens.com

11–20 of 128 posts

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#11

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…

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?

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#12
post #8

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.

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.

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.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

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

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#14

> 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 o…

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

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#15

Earlier quoted context omitted.

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.

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.

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.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#16
post #15

Earlier quoted context omitted.

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.

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

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.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#17

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…

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?

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?

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#18

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…

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?

[deleted]

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#19
Bruce Perens answered questions today on Slashdot about his position.

https://linux.slashdot.org/story/17/07/09/188246/bruce-peren...

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

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#20

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…

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?

On what basis do you claim that grsecurity is "snake oil"?

I will await your comprehensive technical rebuttal of its feature set and implementation, which you have no doubt carefully analyzed.

Post reply on HN