31–40 of 128 posts
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…
So where do you draw the line?
Earlier quoted context omitted.
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.
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.
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.
> 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…
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…
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.
Linux is full of local root exploits and while most script-kiddies just exploit your WordPress plugin and mine some coins or setup a DDoS script that works until someone notice it, having root and a rootkit on machines is probably the goal of any serious intruder - especially if it's servers on organisations and stuff like that.
It also means depeding on the exploit that you can escape Docker, LXC or even KVM/QEMU - rarely but it has been done.
Earlier quoted context omitted.
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.
"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,…
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.…
I don't follow this logic. Red Hat distributes the entire source of the kernels they ship, in a form that anyone can use, change, and redistribute. That satisfies the legal definition and the spirit of the GPL. They do not prohibit their paying customers from enjoying any of the rights guaranteed by the GPL.
grsecurity allegedly prohibits people from doing that.
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.…
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…
Grsecurity is far more integrated into the Linux kernel than a graphics driver. It patches huge swaths of Linux core code. Nvidia is distributing a blob with a few hooks to make it work as a Linux driver. It doesn't touch core Linux code in any way; it adds a driver. One could complain about Nvidia, too, and I wouldn't be bothered by that (I prefer OSS drivers), but to say that it's the same as Grsecurity is disingen…
Earlier quoted context omitted.
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, confirmati…
Out of curiosity, how did you determine that someone was trying to exploit you? And that the kernel crash was due to an attack?