Grsecurity: Potential contributory infringement and breach of contract risk • Hacker News Board

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

#91

Post by SAI_Peregrinus » Mon, Jul 10, 2017, 4:07 AM UTC

muppetman wrote: post #77

sillysaurus3 wrote: post #40

Earlier quoted context omitted.

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.

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.

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

#92

Post by [deleted] » Mon, Jul 10, 2017, 4:18 AM UTC

gizmo686 wrote: post #75

drewcrawford wrote: post #66

Earlier quoted context omitted.

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

[deleted]

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

#93

Post by averagewall » Mon, Jul 10, 2017, 4:52 AM UTC

Can someone explain how the GPL covers Grsecurity at all? It sounds like it's entirely their own code they wrote themselves and have all the rights to. It just happens to be something that their customers are going to use with GPL Linux. They're not distributing any GPL code are they? I can't believe a derivative work can include something that is merely compatible with GPL code but doesn't actually contain any. Or does it? Have they copied and pasted GPL code into the Grsecurity patch? In that case, then it does make sense that it should be GPL'd too.

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

#94

Post by amluto » Mon, Jul 10, 2017, 4:57 AM UTC

averagewall wrote: post #93

Can someone explain how the GPL covers Grsecurity at all? It sounds like it's entirely their own code they wrote themselves and have all the rights to. It just happens to be something that their customers are going to use with GPL Linux. They're not distributing any GPL code are they? I can't believe a derivative work can include something that is merely compatible with GPL code but doesn't actually contain any. Or d…

If you open an old version of the patch, you'll find that it adds, removes, and changes lines in the middle of existing Linux functions. If it's not a derivative work, I don't know what is.

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

#95

Post by tptacek » Mon, Jul 10, 2017, 4:59 AM UTC

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?

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.

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

#96

Post by averagewall » Mon, Jul 10, 2017, 5:02 AM UTC

amluto wrote: post #94

averagewall wrote: post #93

Can someone explain how the GPL covers Grsecurity at all? It sounds like it's entirely their own code they wrote themselves and have all the rights to. It just happens to be something that their customers are going to use with GPL Linux. They're not distributing any GPL code are they? I can't believe a derivative work can include something that is merely compatible with GPL code but doesn't actually contain any. Or d…

If you open an old version of the patch, you'll find that it adds, removes, and changes lines in the middle of existing Linux functions. If it's not a derivative work, I don't know what is.

You mean it contains copies of existing Linux functions which the Grsecurity authors have edited? That makes sense. A lot of the comments here seem to be about how tightly it interfaces with Linux, which is surely a different thing.

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

#97

Post by amluto » Mon, Jul 10, 2017, 5:22 AM UTC

averagewall wrote: post #96

amluto wrote: post #94

Earlier quoted context omitted.

If you open an old version of the patch, you'll find that it adds, removes, and changes lines in the middle of existing Linux functions. If it's not a derivative work, I don't know what is.

You mean it contains copies of existing Linux functions which the Grsecurity authors have edited? That makes sense. A lot of the comments here seem to be about how tightly it interfaces with Linux, which is surely a different thing.

This is a little snippet of grsecurity:

   static void account_kernel_stack(struct task_struct *tsk, int account)
   {
  -       void *stack = task_stack_page(tsk);
          struct vm_struct *vm = task_stack_vm_area(tsk);
   
          BUILD_BUG_ON(IS_ENABLED(CONFIG_VMAP_STACK) && PAGE_SIZE % 1024 != 0);
  @@ -303,8 +357,12 @@ static void account_kernel_stack(struct task_struct *tsk, int account)
                   * All stack pages are in the same zone and belong to the
                   * same memcg.
                   */
  +#ifdef CONFIG_GRKERNSEC_KSTACKOVERFLOW
  +               struct page *first_page = virt_to_page(tsk->lowmem_stack);
  +#else
  +               void *stack = task_stack_page(tsk);
                  struct page *first_page = virt_to_page(stack);
  -
  +#endif
                  mod_zone_page_state(page_zone(first_page), NR_KERNEL_STACK_KB,
                                      THREAD_SIZE / 1024 * account);

Grsecurity isn't Linux plus some additional code. It's a modified version of Linux. Saying that a Linux 4.11 kernel patched with grsecurity isn't a derived work of Linux 4.11 is like saying that a Linux 4.11 kernel patched with patch-4.12.patch [1], otherwise known as Linux 4.12, is not a derived work of 4.11

[1] https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.12.xz

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

#98

Post by cthalupa » Mon, Jul 10, 2017, 6:16 AM UTC

tptacek wrote: post #95

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?

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.

Care to refute? We've got quotes from Linus himself in this thread that show a belief that their products do not provide value.

I'd say that while Linus is generally inflammatory, he's also generally correct. I don't know that what SwellJoe has said is any worse. Do you believe Linus should retract and apologize as well?

This request is genuine - you're a well respected voice in the security world, and I'd be curious to see your take on this. I've never seen sufficient evidence to prove the grsecurity claims that they make the kernel more secure in a meaningful way, and if there are outside experts that have evidence of this, I think it would be beneficial to share that evidence.

Regardless of that, however, I do think it's damaging to support a company that is flagrantly violating the GPL. It's not a license I particularly care for, as more of a BSD/MIT type person, but I do think that if you make money as a derivative work of something, you should damn well follow the license of the work you're deriving from.

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

#99

Post by cthalupa » Mon, Jul 10, 2017, 6:18 AM UTC

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…

The second situation certainly sounds like a successful exploitation to me. A denial of service attack is still a successful exploit.

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

#100

Post by cthalupa » Mon, Jul 10, 2017, 6:29 AM UTC

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…

It's not that grsecurity is useless without the kernel, it's that it patches the kernel. It HAS to be a derivative work of the kernel, since that's what it is modifying.