12 ms·

Grsecurity: Potential contributory infringement and breach of contract risk

121 points by SwellJoe 9y ago

zzalpha 9y ago
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 https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the software. Seems like a grey area as to whether those conditions at enough to violate the GPL under which the Linux kernel is licensed. Original comment: I don't buy it. Grsecurity isn't distributed as a derivative work of the Linux kernel. 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.
- DannyBee 9y ago
  "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.
  - deleted 9y ago
    [deleted]
  - resf 9y ago
    Nvidia have a lot of money, so the law is on their side.
- simion314 9y ago
  So where do you draw the line?
  - deleted 9y ago
    [deleted]
- deleted 9y ago
  [deleted]
- tw04 9y ago
  Given it's closed source we don't know for sure, but IIRC the Nvidia Linux driver shares a ton of code (majority?) with the Windows driver, so one could argue that the bulk of the code "works" just fine without Linux. Grsecurity definitely can't make that claim.
- SwellJoe 9y ago
  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 disingenuous (or lacks deep enough comprehension of the problem to comment on the subject).
  - zzalpha 9y ago
    Your last parenthetical is clearly correct. I misunderstood Peren's argument and have updated my comment accordingly.
- microwavecamera 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - fooker 9y ago
    >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. That is not actually true. That's why LGPL exists.
    - microwavecamera 9y ago
      So I went and read up on it again. Apparently there's no clear consensus on the dynamic linking issue (still). Warning this post may get long. Here goes, so over at gnu.org in the FAQ it says this: "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly." But gnu.org also states: "If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL." But over at the Wikipedia article there's this: "Some people believe that while static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak copyleft). Linux author Linus Torvalds agrees that dynamic linking can create derived works but disagrees over the circumstances. A Novell lawyer has written that dynamic linking not being derivative "makes sense" but is not "clear-cut", and that evidence for good-intentioned dynamic linking can be seen by the existence of proprietary Linux kernel drivers." Now Lawrence Rosen, one-time Open Source Initiative general counsel argues this: "The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work." But what there's more! The GPLv2 allows for a linking exception clause if the original developer(s) want to offer it. "If you're using GPLv2, you can provide your own exception to the license's terms. The following license notice will do that. Again, you must replace all the text in brackets with text that is appropriate for your program. If not everybody can distribute source for the libraries you intend to link with, you should remove the text in braces; otherwise, just remove the braces themselves." Much of it seems to come down to intent and good faith. While the pure application GPLv3 pretty much says no to linking, both dynamic and static, the legal definition of what constitutes a derivative work creates a grey area. It seems to come down to the intent of the developer(s) who license it as to whether it would be enforced that way but the dynamic linking issue is untested in court so no one seems to be sure if it's enforceable. Who knows? GNU, making simple things complicated since 1983.
- vacri 9y ago
  > Just because it's useless without the kernel doesn't make it a derivative work. What's your definition of a derivative work?
- pcwalton 9y ago
  But NVIDIA is violating the GPL. (At least, according to many lawyers.)
- cthalupa 9y ago
  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.
43224gg252 9y ago
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 appear to have some kind of internet defense force or something defending them at every turn but it's become more and more apparent lately that grsec is a low-quality code base maintained by programmer(s) with bad attitudes and superiority complexes. I've been in tech for quite some time and never encountered anyone using grsec patches. They do a really good job of marketing their product on tech forums though.
- SwellJoe 9y ago
  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?
  - muppetman 9y ago
    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, confirmation bias and all that) The fact the kernel protection project are trying to take grsecurity and get it implemented into the kernel also suggests to me that it's not snake oil. So I'm curious as to why you think it is?
    - SwellJoe 9y ago
      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.
makomk 9y ago
I'm curious why the same argument wouldn't apply to Red Hat Enterprise Linux and all its customers, since they apply the same policy of terminating the license of anyone who redistributes it to their kernel patch set.
- SwellJoe 9y ago
  That's not accurate. Everything Red Hat does is OSS. Their kernel patches are developed in the open, and available to anyone. The only thing they restrict is binary distribution.
  - yjftsjthsd-h 9y ago
    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.
    - makomk 9y ago
      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. This is obviously nicer than the gresecuriy approach but there's no obvious reason why it's any more legal.
      - protomyth 9y ago
        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.
drewcrawford 9y ago
> 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 of Grsecurity. GPL version 2 section 6 explicitly prohibits the addition of terms such as this redistribution prohibition. This is a fundamental misunderstanding of the GPL. The GPL merely requires corresponding source to be made available alongside binaries, so if you get a binary from someone you have a right to the corresponding source from that person. It does not require anyone to offer you a binary; it merely says if they did, you can get the corresponding source. GRSecurity has no obligation to provide you a binary, they can decline to offer you one because you have a silly walk or a 13-character username or you exercised your rights under the GPL. The GPL does not entitle you to product updates or to continue to be a customer of someone who doesn't want you as a customer, it merely entitles you to corresponding source for binaries. Some would say GRSecurity's practice violates the spirit of the GPL, but the GPL is not a spiritual entity, it's a legal document, and if you want a legal document that produces a different outcome you can write one up. Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff.
- SwellJoe 9y ago
  "Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff." I don't know about Oracle, but I know about Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it, they distribute it freely themselves, and help maintain a free distribution of RHEL called CentOS built from the same sources they use for RHEL. There is no reasonable way to compare Red Hat's policies about source distribution and availability to grsecurity.
  - 9y ago
MilnerRoute 9y ago
Bruce Perens answered questions today on Slashdot about his position. https://linux.slashdot.org/story/17/07/09/188246/bruce-perens-warns-grsecurity-breaches-the-linux-kernels-gpl-license https://linux.slashdot.org/story/17/07/09/188246/bruce-peren... "It's important to consider the goals of the GPL," he writes at one point. "You get great Free Software, but it's not a gift. It is sharing with rules that must be followed. You are required to keep it Free. And one of the implied purposes of the GPL is to cause more great Free Software to be made. This means that derivative works that are not shared really go against the purpose as well as the wording of the GPL."
yuhong 9y ago
I wonder what is the current status of the Wind River debacle.
simcop2387 9y ago
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 reported threat of no longer being allowed to be a customer of theirs if I provide the legally required source to my customer, does this mean I can no longer reconcile their two licenses and means that I cannot use their kernel patches for my customers?
- SwellJoe 9y ago
  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.
  - simcop2387 9y ago
    That's what I thought was going on from the discussion. Glad to see that it's not just me reading it that way. I'd think then that if GRSec is doing it, and intending to use it that way (I am not a lawyer) then it would appear to me that the assertion that they're violating the GPL since they're adding another restriction on distribution.
  - lokedhs 9y ago
    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.
    - simcop2387 9y ago
averagewall 9y ago
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.
- amluto 9y ago
  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.
  - averagewall 9y ago
    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.
    - amluto 9y ago
      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 https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.12.xz
vectorEQ 9y ago
grsecurity is a good effort, if you dont like it dont use it but dont complain about people trying to make a turd less of a turd even if it is of your opinion they fail at it. alot of people sell software that 'only functions on linux', people even sell linux based appliances, they all leave the licence files etc. neatly tucked away somewhere for licence nazis to find >.>. people who critisize grsecurity and praise linux probarbly dont care much about the rootkits in their systems >.>
lawnchair_larry 9y ago
LOL. Please, just bow out on topics related to security. You are spreading misinformation.
- dang 9y ago
  Personal attacks will get you banned on HN. Surely you know that? Please don't do this again. We detached this comment from https://news.ycombinator.com/item?id=14732721 https://news.ycombinator.com/item?id=14732721 and marked it off-topic.
- deleted 9y ago
  [deleted]
mrsteveman1 9y ago
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 https://grsecurity.net/agree/agreement.php [1] https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html
bhenc 9y ago
I think it is unfair to attack the grsecurity guys like this. They've been providing their patches free of charge for years only to have their work abused. I mean, this whole situation seems a lot like the one described in the following articles, and afaik RedHat is still not facing any lawsuits: https://lwn.net/Articles/432012/ https://lwn.net/Articles/432012/ http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell_with_change_to_source_code_packaging/ http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracl... Now RedHat has the benefit that they claim they're "upstream first", but afaik ASLR originated with the grsecurity guys, so there is grsecurity stuff in the vanilla kernel. Is ASLR snake oil? I don't see how the situation is different between how grsecurity did things and RedHat. Between going out of business and working on the boundary of the GPL, they chose to stay in business. More importantly, how would you deal with publishing under the GPL and making money off of it? This whole discussion reminds me of this article: http://widgetsandshit.com/teddziuba/2010/01/i-love-the-gpl-except-when-it.html http://widgetsandshit.com/teddziuba/2010/01/i-love-the-gpl-e... The way things are going, the best direction to take if you want to produce GPL code is to have another job unrelated to programming to earn enough to code in your free time. It's really sad if you think of the megacorps that are making billions off of FOSS. I'll end up with a quote by Steve Jobs: By the way, what have you done that’s so great? Do you create anything, or just criticize others work and belittle their motivations? http://widgetsandshit.com/teddziuba/2010/05/the-future-of-apples-curated-computing.html http://widgetsandshit.com/teddziuba/2010/05/the-future-of-ap...

121 points by SwellJoe 9y ago

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 https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the software. Seems like a grey area as to whether those conditions at enough to violate the GPL under which the Linux kernel is licensed. Original comment: I don't buy it. Grsecurity isn't distributed as a derivative work of the Linux kernel. 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.

DannyBee 9y ago
"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.
- deleted 9y ago
  [deleted]
- resf 9y ago
  Nvidia have a lot of money, so the law is on their side.
simion314 9y ago
So where do you draw the line?
- deleted 9y ago
  [deleted]
deleted 9y ago
[deleted]
tw04 9y ago
Given it's closed source we don't know for sure, but IIRC the Nvidia Linux driver shares a ton of code (majority?) with the Windows driver, so one could argue that the bulk of the code "works" just fine without Linux. Grsecurity definitely can't make that claim.
SwellJoe 9y ago
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 disingenuous (or lacks deep enough comprehension of the problem to comment on the subject).
- zzalpha 9y ago
  Your last parenthetical is clearly correct. I misunderstood Peren's argument and have updated my comment accordingly.
microwavecamera 9y ago
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.
- deleted 9y ago
  [deleted]
- fooker 9y ago
  >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. That is not actually true. That's why LGPL exists.
  - microwavecamera 9y ago
    So I went and read up on it again. Apparently there's no clear consensus on the dynamic linking issue (still). Warning this post may get long. Here goes, so over at gnu.org in the FAQ it says this: "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly." But gnu.org also states: "If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL." But over at the Wikipedia article there's this: "Some people believe that while static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak copyleft). Linux author Linus Torvalds agrees that dynamic linking can create derived works but disagrees over the circumstances. A Novell lawyer has written that dynamic linking not being derivative "makes sense" but is not "clear-cut", and that evidence for good-intentioned dynamic linking can be seen by the existence of proprietary Linux kernel drivers." Now Lawrence Rosen, one-time Open Source Initiative general counsel argues this: "The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work." But what there's more! The GPLv2 allows for a linking exception clause if the original developer(s) want to offer it. "If you're using GPLv2, you can provide your own exception to the license's terms. The following license notice will do that. Again, you must replace all the text in brackets with text that is appropriate for your program. If not everybody can distribute source for the libraries you intend to link with, you should remove the text in braces; otherwise, just remove the braces themselves." Much of it seems to come down to intent and good faith. While the pure application GPLv3 pretty much says no to linking, both dynamic and static, the legal definition of what constitutes a derivative work creates a grey area. It seems to come down to the intent of the developer(s) who license it as to whether it would be enforced that way but the dynamic linking issue is untested in court so no one seems to be sure if it's enforceable. Who knows? GNU, making simple things complicated since 1983.
vacri 9y ago
> Just because it's useless without the kernel doesn't make it a derivative work. What's your definition of a derivative work?
pcwalton 9y ago
But NVIDIA is violating the GPL. (At least, according to many lawyers.)
cthalupa 9y ago
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.

43224gg252 9y ago

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 appear to have some kind of internet defense force or something defending them at every turn but it's become more and more apparent lately that grsec is a low-quality code base maintained by programmer(s) with bad attitudes and superiority complexes. I've been in tech for quite some time and never encountered anyone using grsec patches. They do a really good job of marketing their product on tech forums though.

SwellJoe 9y ago
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?
- muppetman 9y ago
  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, confirmation bias and all that) The fact the kernel protection project are trying to take grsecurity and get it implemented into the kernel also suggests to me that it's not snake oil. So I'm curious as to why you think it is?
  - SwellJoe 9y ago
    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.

makomk 9y ago

I'm curious why the same argument wouldn't apply to Red Hat Enterprise Linux and all its customers, since they apply the same policy of terminating the license of anyone who redistributes it to their kernel patch set.

SwellJoe 9y ago
That's not accurate. Everything Red Hat does is OSS. Their kernel patches are developed in the open, and available to anyone. The only thing they restrict is binary distribution.
- yjftsjthsd-h 9y ago
  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.
  - makomk 9y ago
    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. This is obviously nicer than the gresecuriy approach but there's no obvious reason why it's any more legal.
    - protomyth 9y ago
      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.

drewcrawford 9y ago

> 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 of Grsecurity. GPL version 2 section 6 explicitly prohibits the addition of terms such as this redistribution prohibition. This is a fundamental misunderstanding of the GPL. The GPL merely requires corresponding source to be made available alongside binaries, so if you get a binary from someone you have a right to the corresponding source from that person. It does not require anyone to offer you a binary; it merely says if they did, you can get the corresponding source. GRSecurity has no obligation to provide you a binary, they can decline to offer you one because you have a silly walk or a 13-character username or you exercised your rights under the GPL. The GPL does not entitle you to product updates or to continue to be a customer of someone who doesn't want you as a customer, it merely entitles you to corresponding source for binaries. Some would say GRSecurity's practice violates the spirit of the GPL, but the GPL is not a spiritual entity, it's a legal document, and if you want a legal document that produces a different outcome you can write one up. Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff.

SwellJoe 9y ago
"Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff." I don't know about Oracle, but I know about Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it, they distribute it freely themselves, and help maintain a free distribution of RHEL called CentOS built from the same sources they use for RHEL. There is no reasonable way to compare Red Hat's policies about source distribution and availability to grsecurity.
- 9y ago

MilnerRoute 9y ago

Bruce Perens answered questions today on Slashdot about his position. https://linux.slashdot.org/story/17/07/09/188246/bruce-perens-warns-grsecurity-breaches-the-linux-kernels-gpl-license https://linux.slashdot.org/story/17/07/09/188246/bruce-peren... "It's important to consider the goals of the GPL," he writes at one point. "You get great Free Software, but it's not a gift. It is sharing with rules that must be followed. You are required to keep it Free. And one of the implied purposes of the GPL is to cause more great Free Software to be made. This means that derivative works that are not shared really go against the purpose as well as the wording of the GPL."

yuhong 9y ago

I wonder what is the current status of the Wind River debacle.

simcop2387 9y ago

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 reported threat of no longer being allowed to be a customer of theirs if I provide the legally required source to my customer, does this mean I can no longer reconcile their two licenses and means that I cannot use their kernel patches for my customers?

SwellJoe 9y ago
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.
- simcop2387 9y ago
  That's what I thought was going on from the discussion. Glad to see that it's not just me reading it that way. I'd think then that if GRSec is doing it, and intending to use it that way (I am not a lawyer) then it would appear to me that the assertion that they're violating the GPL since they're adding another restriction on distribution.
- lokedhs 9y ago
  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.
  - simcop2387 9y ago

averagewall 9y ago

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.

amluto 9y ago
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.
- averagewall 9y ago
  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.
  - amluto 9y ago
    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 https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.12.xz

vectorEQ 9y ago

grsecurity is a good effort, if you dont like it dont use it but dont complain about people trying to make a turd less of a turd even if it is of your opinion they fail at it. alot of people sell software that 'only functions on linux', people even sell linux based appliances, they all leave the licence files etc. neatly tucked away somewhere for licence nazis to find >.>. people who critisize grsecurity and praise linux probarbly dont care much about the rootkits in their systems >.>

lawnchair_larry 9y ago

LOL. Please, just bow out on topics related to security. You are spreading misinformation.

dang 9y ago
Personal attacks will get you banned on HN. Surely you know that? Please don't do this again. We detached this comment from https://news.ycombinator.com/item?id=14732721 https://news.ycombinator.com/item?id=14732721 and marked it off-topic.
deleted 9y ago
[deleted]

mrsteveman1 9y ago

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 https://grsecurity.net/agree/agreement.php [1] https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html

bhenc 9y ago

I think it is unfair to attack the grsecurity guys like this. They've been providing their patches free of charge for years only to have their work abused. I mean, this whole situation seems a lot like the one described in the following articles, and afaik RedHat is still not facing any lawsuits: https://lwn.net/Articles/432012/ https://lwn.net/Articles/432012/ http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell_with_change_to_source_code_packaging/ http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracl... Now RedHat has the benefit that they claim they're "upstream first", but afaik ASLR originated with the grsecurity guys, so there is grsecurity stuff in the vanilla kernel. Is ASLR snake oil? I don't see how the situation is different between how grsecurity did things and RedHat. Between going out of business and working on the boundary of the GPL, they chose to stay in business. More importantly, how would you deal with publishing under the GPL and making money off of it? This whole discussion reminds me of this article: http://widgetsandshit.com/teddziuba/2010/01/i-love-the-gpl-except-when-it.html http://widgetsandshit.com/teddziuba/2010/01/i-love-the-gpl-e... The way things are going, the best direction to take if you want to produce GPL code is to have another job unrelated to programming to earn enough to code in your free time. It's really sad if you think of the megacorps that are making billions off of FOSS. I'll end up with a quote by Steve Jobs: By the way, what have you done that’s so great? Do you create anything, or just criticize others work and belittle their motivations? http://widgetsandshit.com/teddziuba/2010/05/the-future-of-apples-curated-computing.html http://widgetsandshit.com/teddziuba/2010/05/the-future-of-ap...