Live data from Hacker News

Grsecurity: Potential contributory infringement and breach of contract risk

perens.com

71–80 of 128 posts

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

#71
post #59

Earlier quoted context omitted.

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

> 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. Are you sure about this? Are you an attorney? I am not. I ask because it was my impression that, more than each individual having a right to free speech, each individual has a right to be free from a certain set of governmental restrictions or punishments for their speech…

Free speech applies to to public (government) entities. You can prevent someone from exercising their rights if they are within your private property. In public spaces this isn't the case, as it's public, but an employer doesn't have to allow any freedoms to their employees (minus human rights violations, which are explicitly stated in law).

So a company could say you aren't allowed to say a single word during work hours while working for them. They would also not have employees.

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

#72

Earlier quoted context omitted.

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

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

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.

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

#73
post #35
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…

"Linux is full of local root exploits"

Prove it.

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

#74

Earlier quoted context omitted.

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

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.

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

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

#75

Earlier quoted context omitted.

In the US, your only "right" to free speech is protection from the government restricting your speech. Indeed, if your employer is the government, then there are significant (but not absolute) limitations on how much they can retaliate for your speech.

No, you also have a right to free speech against private actors (in certain circumstances). For one example, see Snyder v. Phelps.

If that case were decided the other way, it would mean that government had a law that restricting their right to free speech. You will notice that they did not have the right to speak at the funeral, because the private entity running the funeral is not obligated to give them freedom of speech.

It is true that there are exceptions to the "congress shall make no laws ..." part of the first amendment; so by analogy, there might be some exceptions to the GPL's "no further restrictions" clause, but you have not explained why grsecurity falls into any of those hypothetical exceptions.

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

#76
post #34

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

The word binary appears nowhere in this article. And indeed, the quote you quoted is saying something entirely different from what you're refuting. It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code. That means GRsec can't tell you not to redistribute their GPLv2 licensed code, as it's a clear violation of the kernel license.

But that's not what they're saying. If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL.

What they will do is terminate your contract and you will not receive further updates.

There GPL does not mandate that you receive updates to anything. All it says is is that no restrictions can be applied on the source code that you have received.

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

#77

Earlier quoted context omitted.

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

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?

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.

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

#78
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…

But NVIDIA is violating the GPL. (At least, according to many lawyers.)

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

#79

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

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.

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.

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

#80
post #44

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

"Their approach has always been 'we don't care if we break anything, we'll just claim it's because we're extra secure'. The thing is a joke, and they are clowns. When they started talking about people taking advantage of them, I stopped trying to be polite about their bullshit. Their patches are pure garbage. Linus"

Pated to save a click. As usual Linus doesn't mince his words :)

Post reply on HN