Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grsecurity: Potential contributory infringement and breach of contract risk

perens.com

Post reply on HN
Print view View original

41–50 of 128 posts

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

#41

Post by mobilethrow »

protomyth wrote: post #36
SwellJoe wrote: post #32

Earlier quoted context omitted.

"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,…

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

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

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

#42

Post by muppetman »

ryanlol wrote: post #29
tayo42 wrote: post #24

Earlier quoted context omitted.

Has there been a serious hack that was caused by a kernel exploit? It seems like the hacks I hear about are caused by something higher up. But I don't exactly keep up with exploits. How viable is a kernel exploit to actually do something? I would think by the time an attacked could actually use one they have already gotten pretty far.

The better question is if there's been a serious hack prevented or significantly mitigated by grsec, and the answer to that is most certainly yes.

It's prevented two exploits on a device I own. One just neutered the exploit (it just didn't work) and the other caused the kernel to panic and crash. So yes, it's stopped two for two that I've seen (this is in the last ~6 years)

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

#43

Post by drewcrawford »

gizmo686 wrote: post #27
drewcrawford wrote: post #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 o…

GPLv2, section 6: "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to…

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text.

It is a fundamental misunderstanding of the law, and it is not (an open) question of law.

In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it. Whether that threat is a restriction on your rights is perhaps a question in philosophy or ethics, but from a legal point of view it's very clear: your employer is not restricting your speech, they are restricting their own hiring policy.

So it is here. Legally speaking, you are not restricted from redistributing the software. You may be restricted from GRSecurity wanting to do business with you afterwards but you don't have a right to be someone's customer under the GPL, you only have the right to corresponding binaries.

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

#44

Post by _wldu »

43224gg252 wrote: post #7

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…

Linus on grsecurity: https://www.spinics.net/lists/kernel/msg2540934.html

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

#45

Post by drewcrawford »

SwellJoe wrote: post #14
drewcrawford wrote: post #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 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 dist…

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

[2] https://www.redhat.com/licenses/cloud_CSSA/Red_Hat_Cloud_Sof...

[3] https://www.redhat.com/licenses/GLOBAL_Appendix_one_English_...

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

#46

Post by bcoates »

nisa wrote: post #35
tayo42 wrote: post #24

Earlier quoted context omitted.

Has there been a serious hack that was caused by a kernel exploit? It seems like the hacks I hear about are caused by something higher up. But I don't exactly keep up with exploits. How viable is a kernel exploit to actually do something? I would think by the time an attacked could actually use one they have already gotten pretty far.

If you are on shared hosting or any kind of machines that depends on the kernel to enforce permissions any kernel hole means ability to rootkit the whole thing, set up persistence and access data from root or other users. There is stuff like kerberos tokens for admins, everyting secret in /etc like ldap passwords, private keys or ability to change read-only code to setup a backdoor. You can tap the admin if he uses t…

I'm honestly surprised that people still bother with multi-user access control. Defense in depth only works if the defenses are actually manned, and it's been pretty clear that nobody's been taking linux local escalation seriously for a very long time.

Shared-hosting is, in practice, a high-trust environment, and trying to patch your way around that sounds like the snakeoil logic of Windows security products.

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

#47

Post by vacri »

zzalpha wrote: post #2

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 This clearly represents additional conditions imposed on the s…

> Just because it's useless without the kernel doesn't make it a derivative work.

What's your definition of a derivative work?

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

#48

Post by aeleos »

clackityhack wrote: post #25
43224gg252 wrote: post #7

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…

Your opinion is clearly borne of sheer ignorance. > Grsec makes the kernel more secure by breaking it. No, their patch set includes many different exploit mitigation techniques, and reduction of the attack surface. > I could make a crappy patch that breaks networking and market it as a security feature because it "prevents intrusion" You could, but this has nothing to do with how grsecurity works.

The issue he is referring to is the grsecurity has a history of allowing breaking patches, allowing bad code, attempting to upstream patches in chunks without splitting them up to make the process easier, and then complaining that their patches are being ignored.

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

#49

Post by resf »

DannyBee wrote: post #3
zzalpha wrote: post #2

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 This clearly represents additional conditions imposed on the s…

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

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

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

#50

Post by chx »

drewcrawford wrote: post #43
gizmo686 wrote: post #27

Earlier quoted context omitted.

GPLv2, section 6: "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to…

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text. It is a fundamental misunderstanding of the law, and it is not (an open) question of law. In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fi…

You are talking nonsense. The only "right to free speech" there is

> Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech

This is fundamentally different from the GPL situation. Much closer is intimidation which is recognized as a criminal offense in many US states.

Post reply on HN