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

21–30 of 128 posts

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

#21

Post by viraptor »

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…

It reads like you don't believe their patches make a difference. They may have bad attitude and weird personal approach to software distribution, but their code does what it should do. Sure, you'll have bugs sometimes like with everything, but I think it's worth acknowledging that they do some serious research and published it for a really long time. Their RBAC existed before LSMs were cool and accessible. Their layers of protection were always explicitly listed as options you can toggle yourself. Their newer ideas like RAP are pretty much the best thing available in terms of ROP protection. And now that recent grsec is not available anymore, people do implement the same mechanisms piece by piece upstream.

I find it disappointing people describe grsec as quoted "prevents intrusion". It's not some dodgy internet protection bundle for windows. You can read exactly what it does and why. If it breaks something, you can either identify which part is incompatible with your system and disable it, or you can report it as a bug.

You're not forced to use it of course. You could write something that breaks the kernel and market it, but no, you could not write grsec level of code most likely.

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

#22

Post by SwellJoe »

muppetman wrote: post #17
SwellJoe wrote: post #11

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…

As I said, I think there are some good ideas in grsecurity. But, I am mistrustful of something built by a small team without outside vetting, particularly when it comes to security sensitive code.

The "snake oil" part is that somewhere along the way, a significant segment of a huge industry has been convinced that features that are standard in the current Linux kernel are only possible with grsecurity. We get feature requests all the time that begin with, "You should integrate grsecurity so that we can do X"...when X is already possible with the mainline kernel. I don't know if it is the grsec marketing folks or the folks who integrate grsec into their products, but somebody is misleading the general public about what is and isn't in mainline.

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

#23

Post by SwellJoe »

clackityhack wrote: post #20
SwellJoe wrote: post #11

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?

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.

I mean, I don't care what you call it. There are good things in grsecurity. But, I'd like to see them go through the normal kernel development process before I trust them.

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

#24

Post by tayo42 »

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…

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.

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

#25

Post by clackityhack »

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.

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

#26

Post by microwavecamera »

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…

The difference with something like Nvidia's proprietary driver is that it interfaces with the kernel through the kernel's API as a kernel module, which is fine under the GPLv2, assuming you're not Richard Stallman. Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your own. Grsecurity is really in a grey area here (I personally think it violates the GPL) because it modifies GPL code with proprietary code and possibly borrows GPL code. It's not interfacing with the kernel via APIs and doesn't work outside the kernel. If it were a kernel module it would be fine.

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

#27

Post by gizmo686 »

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

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.

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

#28

Post by mkl »

protomyth wrote: post #16
makomk wrote: post #15

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.

If I understand it correctly, you can distribute Red Hat's source all you want, but it's up to you to figure out which bits of the kernel that is. That extra information is not part of the code.

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

#29

Post by ryanlol »

tayo42 wrote: post #24
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…

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.

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

#30

Post by [deleted] »

microwavecamera wrote: post #26
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…

The difference with something like Nvidia's proprietary driver is that it interfaces with the kernel through the kernel's API as a kernel module, which is fine under the GPLv2, assuming you're not Richard Stallman. Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your…

[deleted]
Post reply on HN