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

111–120 of 128 posts

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

#111

Post by Loony2 »

muppetman wrote: post #42
ryanlol wrote: post #29

Earlier quoted context omitted.

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)

That's the thing though, can you prove that you haven't been exploited several times that you didn't notice and grsec which grsec didn't mitigate?

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

#112

Post by knorker »

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…

I used grsec for a decade, both professionally and privately.

It prevented every single kernel exploit that came out during that time.

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

#113

Post by knorker »

SwellJoe wrote: post #11
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…

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?

Snake oil? I ran grsec for a decade and it prevented every single kernel exploit that came out during that time. All of them.

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

#114

Post by knorker »

SwellJoe wrote: post #101
tptacek wrote: post #95

Earlier quoted context omitted.

I don't think it's at all reasonable to refer to Grsecurity as "snake oil". I think it was a mistake to say that, and you should probably retract and apologize. You don't have to like Grsecurity, or recommend it. Lots of people don't. But you're a professional working in this field and what you've written on this thread doesn't meet that standard.

You'd know better than I would, though I'm not inclined to apologize. I will use more mildly negative language henceforth, however. My problems with Grsecurity are, in order of importance: - This whole licensing thing. I like the GPL. I publish much of my software under the GPL. I want the GPL to be a real thing that we all respect and abide by. When someone breaks that social contract, we all lose. - The lack of eff…

> The lack of effort to work with the rest of the kernel community.

It's not lack of effort. There's blame to be had on both sides, but for a long time (more than a decade) the kernel community stonewalled any security ideas because they just didn't care about mitigating unknown vulnerabilities. They thought it fine to just fix them after they're found, and have everyone recompile.

There's a few articles on this relationship, but it's not as one-sided as you seem to be saying.

The fact that it took order of a decade (I can't be bothered to look up actual years right now) between grsec adding non-executable pages to mainline Linux doing it is embarrassing.

The linux kernel community could and should have re-invented non-executable pages during that time, if nothing else, like when OpenBSD reinvented it and pretended they were first.

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

#115

Post by sanxiyn »

sigjuice wrote: post #108
mkl wrote: post #103

Earlier quoted context omitted.

The patch metadata: which lines have changed for what purpose.

Sorry, I am still not sure what you mean. Could you point me at an example of 'patch metadata'? Thanks!

Here is an example of patch metadata, in this case for Debian: https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian...

"Without patch metadata" would be a single file patch.

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

#116

Post by ryanlol »

SAI_Peregrinus wrote: post #91
muppetman wrote: post #77

Earlier quoted context omitted.

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.

Since crashes (especially segfaults) are often indications of an exploitable vulnerability causing the kernel to crash isn't exactly a good thing. It prevented one attack, caused a (probably short) denial of service, and may be further exploitable.

Grsec doesn't magically make bugs go away, it just makes many of them unexploitable, or at least very hard to exploit.

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

#117

Post by tptacek »

SwellJoe wrote: post #101
tptacek wrote: post #95

Earlier quoted context omitted.

I don't think it's at all reasonable to refer to Grsecurity as "snake oil". I think it was a mistake to say that, and you should probably retract and apologize. You don't have to like Grsecurity, or recommend it. Lots of people don't. But you're a professional working in this field and what you've written on this thread doesn't meet that standard.

You'd know better than I would, though I'm not inclined to apologize. I will use more mildly negative language henceforth, however. My problems with Grsecurity are, in order of importance: - This whole licensing thing. I like the GPL. I publish much of my software under the GPL. I want the GPL to be a real thing that we all respect and abide by. When someone breaks that social contract, we all lose. - The lack of eff…

I don't expect or ask you to praise it, but in software security, "snake oil" has a particular meaning that absolutely does not apply to Grsecurity.

Grsecurity might not be appropriate for the kinds of systems you deploy --- or, even, in your professional judgement, for any production system!

But "snake oil" refers to security products that don't do anything, and that are built in bad faith to bilk users out of their money. Grsecurity clearly isn't that, as anyone can see by Googling (just for instance) "RAP RIP ROP."

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

#118

Post by lawnchair_larry »

SwellJoe wrote: post #11
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…

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?

Snake oil? Being that you couldn't be further off the mark, you really should not be speaking on this topic.

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

#120

Post by mrsteveman1 »

To date, all of the discussion over what GRsec has done is about distribution rights, but it appears the GRsec agreement[0] also contains this:

> If the User has received pricing for the stable patches on a specific product, use of the patches on additional products without the consent of the Company will result in termination of access to future updates of grsecurity stable patches and changelogs.

So while the patches are derivative works of the upstream kernel, which is GPL licensed, they're attempting to restrict the use of the patched kernel source as well by requiring "consent" to use the combined work, the bulk of which was not written by the GRsec developers and has been licensed directly from the upstream kernel authors to anyone who receives it.

That directly contradicts freedom 0: the freedom to run the program as you wish, for any purpose.

[0] https://grsecurity.net/agree/agreement.php

[1] https://www.gnu.org/philosophy/free-sw.en.html

Post reply on HN