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.
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.
"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.
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.
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).
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.
>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.
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.
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.
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.
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, 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.
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.
Unfortunately "small team" as in giving us their private time, describes lots of security-relevant software we're using every day. GPG was a recent example in need of funding.
I'm not sure what you mean by no vetting though. There's quite a bit of discussion related to grsec. A small team is a small team - it doesn't need to be a corporation to work. It may actually work well because it's a small team.
That's true. But, many people I trust have had pretty negative things to say about Grsecurity. I'm not well-versed enough in the subject area to make a good decision on my own, but if I have to choose who to listen to about Linux kernel issues and it comes down to Linus or some other dudes, I'm listening to Linus.
But, that's orthogonal to the problem of small, poorly funded, teams ending up being responsible for major infrastructure, including major security infrastructure. The kernel is one of the few really important pieces that isn't understaffed or underfunded. So, generally, I just trust that the kernel team and my distro of choice are doing good things and use what they give me.
I'm not afraid to patch the kernel, and I've even maintained custom kernel modules and kernel packages in the past, but I'm not going to slap random stuff into my kernel just because a company that profits from it tells me it's better, especially when Linus says it is "garbage" (his word, not mine).
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.
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.
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.
Linus' take on security patches is a highly debated topic. Not only with the grsec guys, but all other people working in netsec. That does not mean Linus is always wrong (though imo he often is regarding that topic) nor that grsec is great of course.
> We've got quotes from Linus himself in this thread that show a belief that their products do not provide value.
All I see is a link to some message where Linus calls these patches pure garbage. There's very little context, and the only borderline technical issue he points out is that grsecurity breaks things. If that is the message you're referring to, it only shows that the grsecurity patches are not aligned with Linus' values. That's a very different thing than the belief that they provide no value.
We know more about Linus' values, based on this old quote:
> I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.
So, for example, if your values place performance and compatibility with old (proprietary..) binaries above all else, then a patch that degrades performance and breaks compatibility with old binaries may as well be "pure garbage."
Yet, a lot of people are willing to sacrifice some performance & compatibility for improved security. Now whether grsecurity does that adequately is a debate I do not wish to take part in.
>If that is the message you're referring to, it only shows that the grsecurity patches are not aligned with Linus' values.
The thread is actually someone asking if it's worth taking a look at how grsecurity handles a large stack guard gap to get ideas for implementation in the kernel. Linus then responds saying to not bother with them.
It's a pretty clear condemnation of them in general, not just their shitty patch submission process.
I think you're missing the point here. It's not helped by the way Linus has expressed himself here. The truth is that there's a fundamental philosophical disagreement here: Linus prioritises not breaking userland, GR security doesn't. Their patches are "crap" because they're large and not in the correct style, not because they don't achieve what they set out to do. Sometimes people take subsets of those patches, clean them up and get them put into the kernel, which is the source of GRS's accusations of "stealing".
The short version is that GR Security have personalities and behaviors very like Linus' own. There's value in GRS, and a fair amount of bad behaviour, but let's be frank, the same's true of Linux.
> Sometimes people take subsets of those patches, clean them up and get them put into the kernel, which is the source of GRS's accusations of "stealing".
This is insane. If their argument had any legal merit, it is because of a bug in gpl and we should patch it. Just based on the accusation of theft, without knowing anything else about them or anything else, I can safely say they're scum bags and no I don't have a Fields medal but I don't retract it.
I do think Linus should have adopted "or later" a long time ago but that's a different discussion.
And when called out on this, they simply block the people saying it.
I'd personally be very skeptical of any security company that values their own tolerance for dealing with people telling them their code sucks over finding out that their code sucks and fixing it. And a lack of good code review and testing is of huge import when it comes to security, at least in my opinion.
Then there's also their weird crusade against (e)BPF without any supporting evidence beyond "It adds more features so that's more attack surface and thus shouldn't ever be added or attempted and we don't believe anyone involved could ever make it secure so there."
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 effort to work with the rest of the kernel community. They've got this huge stack of patches (and it is huge), they're selling it to a bunch of folks (some of whom probably know enough to be making security decisions, many of whom probably don't), and yet they don't really seem interested in being a member of the OSS community.
- There's a recurring theme (even before now, I've heard this argument) of people asserting that someone attacked their server, and, because they had grsec, it crashed instead of allowing the attacker to exploit the system. As though that's not a successful attack in and of itself. The quality of grsecurity code has been called into question by more than one kernel dev, including Linus.
- There's some misleading marketing going on somewhere. I happen to work in the industry sort of parallel to grsecurity. We have a handful of the same customers, there's some overlap in the systems we see and the ones they exist on. For whatever reason, our users who have grsecurity on their systems are the most poorly informed about how the security features of a Linux system fit together (and they think all of them come from grsecurity, even though usually it's none of the ones we're talking about or helping them with). I don't know if grsecurity folks are misleading their customers, or people are just filling in the blanks with where security comes from (obviously it's the security product they paid money for, rather than the kernel itself which was free and thus obviously worthless). It's like the Fox News of kernel patches, somehow messing with it makes people less knowledgeable about the security of their systems.
It's a personal pet peeve, I guess. But, there are, as I said, good ideas in grsecurity. I wish they'd go through the usual process of getting things into the kernel. As it is, they've got a cool research kernel that's unfortunately been pushed into production on some of the most dangerous systems out there (shared hosting and multi-tenancy systems that have barely trusted users and frequently run poorly maintained web apps that often expose the system to untrusted code).
I'm rambling a bit here, but my point is, I won't call it snake oil anymore, but I'm probably not gonna shower it with praise, either. The folks building it are clearly very smart. I really don't mean to denigrate their skills, their experience, or even the software they've built. I just wish they worked with the kernel community more, and I wish whoever is spreading around myths about kernel security and how grsec interacts with it would stop doing so.
> 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.
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."
I should probably just refrain from participating in esoteric security topics from now on; it's above my pay grade. I'll stick to complaining about their licensing.
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.
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.
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)
If you are on shared hosting or any kind of machines that depends on the kernel to enforce permissions any kernel hole means ability to rootkit the whole thing, set up persistence and access data from root or other users. There is stuff like kerberos tokens for admins, everyting secret in /etc like ldap passwords, private keys or ability to change read-only code to setup a backdoor. You can tap the admin if he uses the machine for SSH hopping - grab backups... the list is endless.
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.
I'm honestly surprised that people still bother with multi-user access control. Defense in depth only works if the defenses are actually manned, and it's been pretty clear that nobody's been taking linux local escalation seriously for a very long time.
Shared-hosting is, in practice, a high-trust environment, and trying to patch your way around that sounds like the snakeoil logic of Windows security products.
Shared hosting is high trust? You are basically one stolen credit card and 5 minutes away from giving strangers SSH access to a host with lot's of customers that often process sensitive data.
Might be true that it's not that important for the cloud crowd where you just use an instance for everything but that that's expensive and not the reality outside of certain bubbles and in the end the problem is just invible to you because Google or Amazon are tightening their hypervisors for you.
Lot's of Hadoop/HPC clusters or university desktops depend on this stuff.
With everyone moving to Docker and Containers the kernel is the only thing that prevents an intruder from owning the host or the cluster - it's a shame that this is not taken seriously - however they still assign CVEs for it.
On a modern cluster node you have software defined networking - having root on a node also means access to different VLANs and stuff like that - most distribued applications just blindly trust anything inside their internal network are a pain the secure (try setting up Hadoop with Kerberos, it's not exactly click&play). A normal setup gives you a SSH key and instant shell on every machine in the cluster.
Also most machines are identical so if you own one, you most probably have the means to own all. You can also get all the configuration management data as root.
It's for sure not a barrier you should use as your last stand but it's something that should be as hard as possible to overcome. Just giving up and saying who cares only makes the job for future intruders easier.
Really? http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html... - there is at least one big one with public exploit every year - someone experienced can probably write exploits for issues that are critical but where there is no public exploit. Than there are lot's of userspace exploits like the recent sudo issues or mysql root exploits, the list is pretty long for linux in '15 und '16 - if you hotpatch or reboot a few times a month and keep packages updated you are probably save (at least I hope so) but if you are unlucky and lazy in keeping up with updates - not so much.
As I've said script kiddies probably fail at exploiting this but if you have valuable infrastructure to maintain and you've got someone talented or bored on the other side or even inside your network i.e. university networks where you can't reboot everything every other day it's not unrealistic.
That certainly sounds pretty bad, but I've browsed through them, and while there have been some doozies, it's also not as dramatic as it seems on the surface.
First up, nearly half of this years priv esc bugs in Linux so far are specific to Android (and most of those involve things like nvidia drivers). That's serious, but not "somebody can get root on my server" serious.
Another handful of them are specific to some driver, some kernel module, or some kernel feature, that would only be used on a subset of systems. Still bad, but it does mean that at any given time, even systems running theoretically exploitable systems often won't be because the feature needed to exploit it isn't turned on and can only be turned on by root. For example, one of the high scoring vulnerabilities requires a user or process with CAP_NET_RAW capability. That has to be granted by root, and would presumably only be granted to trusted users and processes.
But, others are pretty scary and would be exploitable in a lot of cases. It's a reminder to stay on top of updates. And, also a reminder that the kernel is a huge surface area for attacks. It sometimes seems like a miracle that any of this stuff works at all.
The issue he is referring to is the grsecurity has a history of allowing breaking patches, allowing bad code, attempting to upstream patches in chunks without splitting them up to make the process easier, and then complaining that their patches are being ignored.
"Their approach has always been 'we don't care if we break anything, we'll just claim it's because we're extra secure'. The thing is a joke, and they are clowns. When they started talking about people taking advantage of them, I stopped trying to be polite about their bullshit. Their patches are pure garbage. Linus"
Pated to save a click. As usual Linus doesn't mince his words :)
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.
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.
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. This is obviously nicer than the gresecuriy approach but there's no obvious reason why it's any more legal.
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.
"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, 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.
Thanks for the answer. Is the removal of the context of the changes generally considered acceptable? We have a Red Hat license, but frankly, I am more a BSD person and our use of Red Hat is a requirement for specific programs.
Yes, it is well-understood to be acceptable. In the past, most commercial Linux distributions were developed behind closed doors in private revision control and pushed out as "complete" source packages. We had these conversations back then (~20 years ago), and the community and the companies involved came to mostly agree about what is and isn't OK. That's opened up a lot in recent years, such that these days "open source" usually means, "we have a public git repository", but it does not have to.
The GPL provides you some basic rights: you can request the source in a usable form, you can change it, you can redistribute it under the same terms.
It does not require access to the process that produced the software.
These days, Red Hat develops almost everything way out in the open. Contrary to all of the talk in this thread where folks (mostly just one guy, actually) keeps implying RH are violating the license or making it hard to get and distribute source, you can see discussions and the actual code being worked on months in advance of what will be in RHEL by following Fedora development. Fedora is developed entirely in public repositories and mailing lists, and it is where much of RHEL development takes place (RHEL trails Fedora by about 12 to 18 months, in terms of versions, and things that will be in RHEL next year are in Fedora today). Red Hat is an excellent OSS company who do damned near everything right, IMHO. Any complaints I might have about some of their practices (like I said elsewhere, I liked having a kernel SRPM that was the mainline kernel plus listed patches, and I miss it being that way) pale in comparison to the good they do for the OSS community.
Just because they make a lot of money doesn't mean they're cheating the community out of anything.
The only thing I'm aware of that Red Hat sort of locks away is their documentation and knowledge base, as well as the binary builds. It contains specific information about patches that backport CVE fixes, bugfixes, etc. The kernel sources are maintained in an internal revision control system and pushed out as a tarball (which is then integrated into CentOS and other RHEL derived distros).
There is a wealth of knowledge in there if you're looking to solve specific enterprisey problems, but it's not necessary to have access to any of it to track what changes Red Hat makes to their kernels and to reproduce them from freely obtainable sources. I don't think you're even prohibited from sharing what you learn from their customer portal resources; though copy-pasting the whole thing into the wild is certainly a copyright and/or license violation and might get you some sort of trouble.
But, the premise of the comparison that Red Hat will somehow penalize someone for distributing RH sources (which has also been alleged in this thread) is just wrong. You can get and copy and modify and redistribute the kernel sources from RH; whether you get it as a paying customer in the form of RHEL or from CentOS for free. Red Hat will not penalize you for doing so, nor will they end any contracts you have with them.
The change to a mashed together tarball rather than a mainline kernel with patches applied was a direct response to Oracle rebuilding RHEL from sources and calling it Oracle Linux. It's unfortunate (I used to maintain a bunch of kernel RPMs, and it was nice having all the independent patches), but it's not a violation of the license, and it's still entirely possible to distribute custom RHEL-based kernels; you just have to actually know what you're doing to do so. There's no more copypasta-custom kernel building, in the general case. If you follow their kernels, maybe keeping your own revision control of them, you can see what changes between each revision, and it would be possible to parse out the specific patches in a lot of cases with relative ease. But, none of that is necessary to be compliant with the GPL.
The GPL requires you make the source code available to anyone you distribute to, and under the same terms as the kernel itself. Red Hat does exactly that (and then some, by maintaining CentOS).
"but there's no obvious reason why it's any more legal."
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.
What is the difference between "patched kernel source" and the "patches that make up their kernel"? It sounds like maybe you are saying that they just provide the source from release to release, not the Git (or similar) history with each commit they make. But since they release the source of each release, it sounds like that satisfies the GPL, and giving customers Git history or equivalent is an additional perk.
This is simply a falsehood. Both SUSE and RHEL provide the corresponding sources for all of their free software packages (regardless of the license) through source RPMs (which were actually created specifically for this purpose).
> 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.
"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.
> Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it
Of course they prohibit it. e.g. from [1]
> This EULA does not permit you to distribute the Programs or their components using Red Hat's trademarks, regardless of whether the copy has been modified. You may make a commercial redistribution of the Programs only if (a) permitted under a separate written agreement with Red Hat authorizing such commercial redistribution, or (b) you remove and replace all occurrences of Red Hat trademarks.
from [2]
> Distributing the Software and Services (or any portion) to a third party outside the Portal or using the Software and/or Services to support a third party without paying for each Instance is a material breach of this Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages
from [3]
> Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as... (d) using Subscription Services in connection with any redistribution of Software
Your first quote covers trademarks. That is unrelated to source code. CentOS ships with a different set of trademarks. If you want to rebuild and redistribute the RH sources, you remove the trademarks. That's well understood and well within the terms of the GPL.
Second refers to binary builds of the software. Also well within the terms of the GPL.
Third refers to the Subscription Service which includes access to binary builds, access to a customer portal with knowledge base, private support tickets, etc.
None of these refer to distribution of source, which is explicitly permitted by Red Hat.
> Your first quote covers trademarks. That is unrelated to source code.
Source code contains trademarks, that is why CentOS has to remove them. If you distribute the source code you get from the RHEL subscription area you have violated your RHEL agreement.
You are not in violation of the GPL, but that is precisely my point: everybody does this, and nobody (except OP) believes it is a GPL violation.
I'm not interested in re-litigating the trademark discussion here. It's not relevant to the grsecurity conversation, and it's been settled for a decade or so. Trademark law is separate from copyright law and really has no place in a copyright discussion.
Red Hat places branding in their own packages, generally, which is easily replaced by distributions...they do their own re-branding in Fedora and CentOS; the trademarks are built to be removable. Red Hat went out of their way to make it easier to build a from-source RHEL without violating trademarks, despite not really having a legal obligation to do so.
My assertion had nothing to do with whether they made it easy or hard to remove their trademarks.
My assertion was that Red Hat customers make agreements with Red Hat in which they agree not to redistribute RHEL. That is directly analogous to the GRSecurity case, except there we are relying on something OP heard thirdhand and in the case of RH we can read the agreements.
"My assertion was that Red Hat customers make agreements with Red Hat in which they agree not to redistribute RHEL. That is directly analogous to the GRSecurity case, except there we are relying on something OP heard thirdhand and in the case of RH we can read the agreements."
Then your assertion is a lie. I feel like I'm talking to a wall.
Red Hat very clearly does not prohibit distribution of the source of their kernel, or any other GPL component of RHEL, and in fact they make it available for free in the form of CentOS, and they do not prohibit others from distributing it either. Everything you've quoted above says nothing about what you keep saying it means.
You don't understand the issue then (and your assertion is patently false as I outlined elsewhere).
First of all, requiring trademark removal is something the FSF considers acceptable so long as it is reasonable to do[1]. Both RHEL and SUSE have all of their branding in specifically labeled packages so it is easy to replace.
Second of all, GRSecurity will always penalise you if you distribute their sources (regardless of whether you remove any trademarks they may have in their source -- which I don't think they do).
The two issues are completely different and you're muddying the waters by bringing up Red Hat, even though the free software community has agreed that removal of trademarks is acceptable[1]. You're bringing up a non-issue in a discussion about an actual issue.
The same goes for SUSE as well. Not only that, but the openSUSE community created an entirely new distribution based on the SLE sources (openSUSE Leap).
"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.
> 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.
It is a fundamental misunderstanding of the law, and it is not (an open) question of law.
In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it. Whether that threat is a restriction on your rights is perhaps a question in philosophy or ethics, but from a legal point of view it's very clear: your employer is not restricting your speech, they are restricting their own hiring policy.
So it is here. Legally speaking, you are not restricted from redistributing the software. You may be restricted from GRSecurity wanting to do business with you afterwards but you don't have a right to be someone's customer under the GPL, you only have the right to corresponding binaries.
You are talking nonsense. The "right to free speech" in the United States has developed over hundreds of years of jurisprudence. It is impossible to summarize here but for starters involves not only Congress but also states (Gitlow v NY) and even private parties (Snyder v. Phelps). I don't mean to suggest it is arbitrarily broad but it is certainly much broader than to say it is "only" the text of the first amendment.
Secondly, "intimidation" carries a very specific legal meaning, for example here's the Montana statute [0]:
(1) A person commits the offense of intimidation when, with the purpose to cause another to perform or to omit the performance of any act, the person communicates to another, under circumstances that reasonably tend to produce a fear that it will be carried out, a threat to perform without lawful authority any of the following acts:
(a) inflict physical harm on the person threatened or any other person;
(b) subject any person to physical confinement or restraint; or
(c) commit any felony.
Unless GRSecurity is threatening to break your legs, kidnap you, or rob your store, they are not intimidating you.
What we are talking about is refusing to do business with you, which is very legal. There are some exceptions, such as if the basis for that refusal is due to your race/sex, or if GRSecurity is a cartel, or if they are refusing in order to obstruct an investigation into some other illegal activity, but I'm not aware of those kinds of facts here.
> In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it.
Are you sure about this? Are you an attorney? I am not.
I ask because it was my impression that, more than each individual having a right to free speech, each individual has a right to be free from a certain set of governmental restrictions or punishments for their speech, and that this is also true of the non-governmental-employer-employee relationship, but the set is smaller.
For instance, it was my impression that:
(A) People who are not governmental employees have the right to be free from the government restricting them from criticizing Congress in most locations at most times (and have the right to be free from the government punishing them for this criticism)
(B) Governmental employees have fewer rights that (A) in certain respects related to their employment
(C) People who are non-governmental employees can generally be fired for their speech, though not for certain speech, like stating that she is pregnant or whistleblowing to the federal government (under some circumstances)
Free speech applies to to public (government) entities. You can prevent someone from exercising their rights if they are within your private property. In public spaces this isn't the case, as it's public, but an employer doesn't have to allow any freedoms to their employees (minus human rights violations, which are explicitly stated in law).
So a company could say you aren't allowed to say a single word during work hours while working for them. They would also not have employees.
In the US, your only "right" to free speech is protection from the government restricting your speech. Indeed, if your employer is the government, then there are significant (but not absolute) limitations on how much they can retaliate for your speech.
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, there might be some exceptions to the GPL's "no further restrictions" clause, but you have not explained why grsecurity falls into any of those hypothetical exceptions.
"In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it."
This is a trolling technique known as derailing. It seems to have worked a little since most of the replies are about "free speech", which isn't what this conversation is about.
The word binary appears nowhere in this article. And indeed, the quote you quoted is saying something entirely different from what you're refuting. It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code. That means GRsec can't tell you not to redistribute their GPLv2 licensed code, as it's a clear violation of the kernel license.
But that's not what they're saying. If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL.
What they will do is terminate your contract and you will not receive further updates.
There GPL does not mandate that you receive updates to anything. All it says is is that no restrictions can be applied on the source code that you have received.
Let's back up for a moment just to make sure we're talking about the same "they." "They" being the author of this article, absolutely said almost verbatim what I claimed they said.
My post: "It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code"
The article: "This is tantamount to the addition of a term to the GPL prohibiting distribution or creating a penalty for distribution. GPL section 6 specifically prohibits any addition of terms."
>If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL.
Now it seems you're talking about GRsec and not the author of the article, but I definitely didn't claim GRsec said anything, I only made assertions about what the article said.
Then, going a step further, what you're arguing is yet another separate issue entirely, which is more relevant but still different than anything in this thread: Your claim is that their contract's rules of punishing someone for redistribution is not covered by GPL section 6. This may well be true, but I would personally guess not.
"You may not impose any further restrictions on the recipients' exercise of the rights granted herein" seems pretty clear cut to me. It implies that you can't impose any further restrictions. You can't even write a contract regarding the terms of redistributing GPLv2 software. And indeed, as far as I can tell, there's absolutely no precedence for being able to do that. If you could do that, then anyone could defeat the GPL by making a contract with sufficient punishment for redistribution.
Seems pretty clear. They cannot stop you from redistributing the binary of v1, and anyone you redistribute the binary to can demand the source if it's not already included. They can say that if they find out you redistributed v1, they're not going to give you v2 in the future, but if you get v2 some other way you can still ask for the source (and whoever distributed that one might not get v3 etc.). There may be further restrictions from trademarks to make redistribution perfectly legal (like CentOS just removing mentions of RHEL) but it can quickly become a lost battle for upstream.
> 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.
While that may be true for Oracle (I doubt it), it's absolutely not true for Red Hat and SUSE. Not only are most of our projects developed in the open under free software licenses in the first place, we provide corresponding source for every package (regardless of the license terms, as long as it's a free software package) through our package manager as source RPMs.
The only restrictions that companies such as Red Hat and SUSE have is related to trademarks and distribution of the binaries that we compiled.
* Trademarks are a completely separate set of laws to copyright, and it has been long accepted in the free software community that as long as it is reasonably easy to remove trademark branding then this is acceptable (in Red Hat's and SUSE's cases, all branding is placed in separate and clearly marked packages -- so you can remove it by replacing those packages)[1].
* As for distribution of binaries, this policy exists for practical reasons and doesn't affect the community (the sources are available and we also provide an entire build service [Open Build Service[2]] that you can use directly to rebuild all of our sources and ISO images if you wished to).
openSUSE Leap is a community distribution created from the SLE sources. CentOS is similarly a distribution built from the RHEL sources.
[ I work for SUSE, and am also an FSF member -- I find spreading of misinformation like this incredibly harmful to the wider community. I would not work for SUSE if I felt that our actions were mistreating users. Opinions my own, obviously. ]
"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."
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?
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.
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.
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.
Yea that's why I specifically mentioned modules in my original comment. It might be possible to argue that you don't get to see the kernel image so it wasn't distributed to you, but if they gave you modules from that kernel that you can load/unload then it'd be a lot harder to make that argument that they weren't distributed to you.
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.
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.
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
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 >.>
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.
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.
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.
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.
127 comments
[ 5.2 ms ] story [ 200 ms ] threadI 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 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.
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).
That is not actually true. That's why LGPL exists.
"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.
What's your definition of a derivative work?
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.
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?
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?
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.
Unfortunately "small team" as in giving us their private time, describes lots of security-relevant software we're using every day. GPG was a recent example in need of funding.
I'm not sure what you mean by no vetting though. There's quite a bit of discussion related to grsec. A small team is a small team - it doesn't need to be a corporation to work. It may actually work well because it's a small team.
But, that's orthogonal to the problem of small, poorly funded, teams ending up being responsible for major infrastructure, including major security infrastructure. The kernel is one of the few really important pieces that isn't understaffed or underfunded. So, generally, I just trust that the kernel team and my distro of choice are doing good things and use what they give me.
I'm not afraid to patch the kernel, and I've even maintained custom kernel modules and kernel packages in the past, but I'm not going to slap random stuff into my kernel just because a company that profits from it tells me it's better, especially when Linus says it is "garbage" (his word, not mine).
Out of curiosity, how did you determine that someone was trying to exploit you? And that the kernel crash was due to an attack?
I will await your comprehensive technical rebuttal of its feature set and implementation, which you have no doubt carefully analyzed.
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.
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.
All I see is a link to some message where Linus calls these patches pure garbage. There's very little context, and the only borderline technical issue he points out is that grsecurity breaks things. If that is the message you're referring to, it only shows that the grsecurity patches are not aligned with Linus' values. That's a very different thing than the belief that they provide no value.
We know more about Linus' values, based on this old quote:
> I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.
So, for example, if your values place performance and compatibility with old (proprietary..) binaries above all else, then a patch that degrades performance and breaks compatibility with old binaries may as well be "pure garbage."
Yet, a lot of people are willing to sacrifice some performance & compatibility for improved security. Now whether grsecurity does that adequately is a debate I do not wish to take part in.
The thread is actually someone asking if it's worth taking a look at how grsecurity handles a large stack guard gap to get ideas for implementation in the kernel. Linus then responds saying to not bother with them.
It's a pretty clear condemnation of them in general, not just their shitty patch submission process.
The short version is that GR Security have personalities and behaviors very like Linus' own. There's value in GRS, and a fair amount of bad behaviour, but let's be frank, the same's true of Linux.
This is insane. If their argument had any legal merit, it is because of a bug in gpl and we should patch it. Just based on the accusation of theft, without knowing anything else about them or anything else, I can safely say they're scum bags and no I don't have a Fields medal but I don't retract it.
I do think Linus should have adopted "or later" a long time ago but that's a different discussion.
It doesn't seem like they are very good at code review or testing, for example:
https://twitter.com/marcan42/status/724745886794833920?lang=...
And when called out on this, they simply block the people saying it.
I'd personally be very skeptical of any security company that values their own tolerance for dealing with people telling them their code sucks over finding out that their code sucks and fixing it. And a lack of good code review and testing is of huge import when it comes to security, at least in my opinion.
Then there's also their weird crusade against (e)BPF without any supporting evidence beyond "It adds more features so that's more attack surface and thus shouldn't ever be added or attempted and we don't believe anyone involved could ever make it secure so there."
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 effort to work with the rest of the kernel community. They've got this huge stack of patches (and it is huge), they're selling it to a bunch of folks (some of whom probably know enough to be making security decisions, many of whom probably don't), and yet they don't really seem interested in being a member of the OSS community.
- There's a recurring theme (even before now, I've heard this argument) of people asserting that someone attacked their server, and, because they had grsec, it crashed instead of allowing the attacker to exploit the system. As though that's not a successful attack in and of itself. The quality of grsecurity code has been called into question by more than one kernel dev, including Linus.
- There's some misleading marketing going on somewhere. I happen to work in the industry sort of parallel to grsecurity. We have a handful of the same customers, there's some overlap in the systems we see and the ones they exist on. For whatever reason, our users who have grsecurity on their systems are the most poorly informed about how the security features of a Linux system fit together (and they think all of them come from grsecurity, even though usually it's none of the ones we're talking about or helping them with). I don't know if grsecurity folks are misleading their customers, or people are just filling in the blanks with where security comes from (obviously it's the security product they paid money for, rather than the kernel itself which was free and thus obviously worthless). It's like the Fox News of kernel patches, somehow messing with it makes people less knowledgeable about the security of their systems.
It's a personal pet peeve, I guess. But, there are, as I said, good ideas in grsecurity. I wish they'd go through the usual process of getting things into the kernel. As it is, they've got a cool research kernel that's unfortunately been pushed into production on some of the most dangerous systems out there (shared hosting and multi-tenancy systems that have barely trusted users and frequently run poorly maintained web apps that often expose the system to untrusted code).
I'm rambling a bit here, but my point is, I won't call it snake oil anymore, but I'm probably not gonna shower it with praise, either. The folks building it are clearly very smart. I really don't mean to denigrate their skills, their experience, or even the software they've built. I just wish they worked with the kernel community more, and I wish whoever is spreading around myths about kernel security and how grsec interacts with it would stop doing so.
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.
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."
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.
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.
Shared-hosting is, in practice, a high-trust environment, and trying to patch your way around that sounds like the snakeoil logic of Windows security products.
Might be true that it's not that important for the cloud crowd where you just use an instance for everything but that that's expensive and not the reality outside of certain bubbles and in the end the problem is just invible to you because Google or Amazon are tightening their hypervisors for you.
Lot's of Hadoop/HPC clusters or university desktops depend on this stuff.
With everyone moving to Docker and Containers the kernel is the only thing that prevents an intruder from owning the host or the cluster - it's a shame that this is not taken seriously - however they still assign CVEs for it.
On a modern cluster node you have software defined networking - having root on a node also means access to different VLANs and stuff like that - most distribued applications just blindly trust anything inside their internal network are a pain the secure (try setting up Hadoop with Kerberos, it's not exactly click&play). A normal setup gives you a SSH key and instant shell on every machine in the cluster.
Also most machines are identical so if you own one, you most probably have the means to own all. You can also get all the configuration management data as root.
It's for sure not a barrier you should use as your last stand but it's something that should be as hard as possible to overcome. Just giving up and saying who cares only makes the job for future intruders easier.
Prove it.
As I've said script kiddies probably fail at exploiting this but if you have valuable infrastructure to maintain and you've got someone talented or bored on the other side or even inside your network i.e. university networks where you can't reboot everything every other day it's not unrealistic.
First up, nearly half of this years priv esc bugs in Linux so far are specific to Android (and most of those involve things like nvidia drivers). That's serious, but not "somebody can get root on my server" serious.
Another handful of them are specific to some driver, some kernel module, or some kernel feature, that would only be used on a subset of systems. Still bad, but it does mean that at any given time, even systems running theoretically exploitable systems often won't be because the feature needed to exploit it isn't turned on and can only be turned on by root. For example, one of the high scoring vulnerabilities requires a user or process with CAP_NET_RAW capability. That has to be granted by root, and would presumably only be granted to trusted users and processes.
But, others are pretty scary and would be exploitable in a lot of cases. It's a reminder to stay on top of updates. And, also a reminder that the kernel is a huge surface area for attacks. It sometimes seems like a miracle that any of this stuff works at all.
> 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.
Pated to save a click. As usual Linus doesn't mince his words :)
It prevented every single kernel exploit that came out during that time.
"Without patch metadata" would be a single file patch.
A CentOS 6 kernel source rpm that I unpacked recently had multiple patch files in it.
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.
The GPL provides you some basic rights: you can request the source in a usable form, you can change it, you can redistribute it under the same terms.
It does not require access to the process that produced the software.
These days, Red Hat develops almost everything way out in the open. Contrary to all of the talk in this thread where folks (mostly just one guy, actually) keeps implying RH are violating the license or making it hard to get and distribute source, you can see discussions and the actual code being worked on months in advance of what will be in RHEL by following Fedora development. Fedora is developed entirely in public repositories and mailing lists, and it is where much of RHEL development takes place (RHEL trails Fedora by about 12 to 18 months, in terms of versions, and things that will be in RHEL next year are in Fedora today). Red Hat is an excellent OSS company who do damned near everything right, IMHO. Any complaints I might have about some of their practices (like I said elsewhere, I liked having a kernel SRPM that was the mainline kernel plus listed patches, and I miss it being that way) pale in comparison to the good they do for the OSS community.
Just because they make a lot of money doesn't mean they're cheating the community out of anything.
There is a wealth of knowledge in there if you're looking to solve specific enterprisey problems, but it's not necessary to have access to any of it to track what changes Red Hat makes to their kernels and to reproduce them from freely obtainable sources. I don't think you're even prohibited from sharing what you learn from their customer portal resources; though copy-pasting the whole thing into the wild is certainly a copyright and/or license violation and might get you some sort of trouble.
But, the premise of the comparison that Red Hat will somehow penalize someone for distributing RH sources (which has also been alleged in this thread) is just wrong. You can get and copy and modify and redistribute the kernel sources from RH; whether you get it as a paying customer in the form of RHEL or from CentOS for free. Red Hat will not penalize you for doing so, nor will they end any contracts you have with them.
The change to a mashed together tarball rather than a mainline kernel with patches applied was a direct response to Oracle rebuilding RHEL from sources and calling it Oracle Linux. It's unfortunate (I used to maintain a bunch of kernel RPMs, and it was nice having all the independent patches), but it's not a violation of the license, and it's still entirely possible to distribute custom RHEL-based kernels; you just have to actually know what you're doing to do so. There's no more copypasta-custom kernel building, in the general case. If you follow their kernels, maybe keeping your own revision control of them, you can see what changes between each revision, and it would be possible to parse out the specific patches in a lot of cases with relative ease. But, none of that is necessary to be compliant with the GPL.
The GPL requires you make the source code available to anyone you distribute to, and under the same terms as the kernel itself. Red Hat does exactly that (and then some, by maintaining CentOS).
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.
I gave a longer rant about this in a separate thread: https://news.ycombinator.com/item?id=14733131
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.
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.
Of course they prohibit it. e.g. from [1]
> This EULA does not permit you to distribute the Programs or their components using Red Hat's trademarks, regardless of whether the copy has been modified. You may make a commercial redistribution of the Programs only if (a) permitted under a separate written agreement with Red Hat authorizing such commercial redistribution, or (b) you remove and replace all occurrences of Red Hat trademarks.
from [2]
> Distributing the Software and Services (or any portion) to a third party outside the Portal or using the Software and/or Services to support a third party without paying for each Instance is a material breach of this Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages
from [3]
> Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as... (d) using Subscription Services in connection with any redistribution of Software
[1] https://www.redhat.com/f/pdf/licenses/GLOBAL_EULA_RHEL_Engli...
[2] https://www.redhat.com/licenses/cloud_CSSA/Red_Hat_Cloud_Sof...
[3] https://www.redhat.com/licenses/GLOBAL_Appendix_one_English_...
Second refers to binary builds of the software. Also well within the terms of the GPL.
Third refers to the Subscription Service which includes access to binary builds, access to a customer portal with knowledge base, private support tickets, etc.
None of these refer to distribution of source, which is explicitly permitted by Red Hat.
Source code contains trademarks, that is why CentOS has to remove them. If you distribute the source code you get from the RHEL subscription area you have violated your RHEL agreement.
You are not in violation of the GPL, but that is precisely my point: everybody does this, and nobody (except OP) believes it is a GPL violation.
Red Hat places branding in their own packages, generally, which is easily replaced by distributions...they do their own re-branding in Fedora and CentOS; the trademarks are built to be removable. Red Hat went out of their way to make it easier to build a from-source RHEL without violating trademarks, despite not really having a legal obligation to do so.
My assertion was that Red Hat customers make agreements with Red Hat in which they agree not to redistribute RHEL. That is directly analogous to the GRSecurity case, except there we are relying on something OP heard thirdhand and in the case of RH we can read the agreements.
Then your assertion is a lie. I feel like I'm talking to a wall.
Red Hat very clearly does not prohibit distribution of the source of their kernel, or any other GPL component of RHEL, and in fact they make it available for free in the form of CentOS, and they do not prohibit others from distributing it either. Everything you've quoted above says nothing about what you keep saying it means.
First of all, requiring trademark removal is something the FSF considers acceptable so long as it is reasonable to do[1]. Both RHEL and SUSE have all of their branding in specifically labeled packages so it is easy to replace.
Second of all, GRSecurity will always penalise you if you distribute their sources (regardless of whether you remove any trademarks they may have in their source -- which I don't think they do).
The two issues are completely different and you're muddying the waters by bringing up Red Hat, even though the free software community has agreed that removal of trademarks is acceptable[1]. You're bringing up a non-issue in a discussion about an actual issue.
[1]: https://www.gnu.org/distros/free-system-distribution-guideli...
They do not restrict you from distributing the source code.
Grsecurity restricts you from distributing the source code.
These are very different things.
"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.
It is a fundamental misunderstanding of the law, and it is not (an open) question of law.
In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it. Whether that threat is a restriction on your rights is perhaps a question in philosophy or ethics, but from a legal point of view it's very clear: your employer is not restricting your speech, they are restricting their own hiring policy.
So it is here. Legally speaking, you are not restricted from redistributing the software. You may be restricted from GRSecurity wanting to do business with you afterwards but you don't have a right to be someone's customer under the GPL, you only have the right to corresponding binaries.
> Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech
This is fundamentally different from the GPL situation. Much closer is intimidation which is recognized as a criminal offense in many US states.
Secondly, "intimidation" carries a very specific legal meaning, for example here's the Montana statute [0]:
Unless GRSecurity is threatening to break your legs, kidnap you, or rob your store, they are not intimidating you.What we are talking about is refusing to do business with you, which is very legal. There are some exceptions, such as if the basis for that refusal is due to your race/sex, or if GRSecurity is a cartel, or if they are refusing in order to obstruct an investigation into some other illegal activity, but I'm not aware of those kinds of facts here.
[0] http://leg.mt.gov/bills/mca/45/5/45-5-203.htm
Are you sure about this? Are you an attorney? I am not.
I ask because it was my impression that, more than each individual having a right to free speech, each individual has a right to be free from a certain set of governmental restrictions or punishments for their speech, and that this is also true of the non-governmental-employer-employee relationship, but the set is smaller.
For instance, it was my impression that:
(A) People who are not governmental employees have the right to be free from the government restricting them from criticizing Congress in most locations at most times (and have the right to be free from the government punishing them for this criticism)
(B) Governmental employees have fewer rights that (A) in certain respects related to their employment
(C) People who are non-governmental employees can generally be fired for their speech, though not for certain speech, like stating that she is pregnant or whistleblowing to the federal government (under some circumstances)
But I am not a lawyer.
So a company could say you aren't allowed to say a single word during work hours while working for them. They would also not have employees.
It is true that there are exceptions to the "congress shall make no laws ..." part of the first amendment; so by analogy, there might be some exceptions to the GPL's "no further restrictions" clause, but you have not explained why grsecurity falls into any of those hypothetical exceptions.
This is a trolling technique known as derailing. It seems to have worked a little since most of the replies are about "free speech", which isn't what this conversation is about.
What they will do is terminate your contract and you will not receive further updates.
There GPL does not mandate that you receive updates to anything. All it says is is that no restrictions can be applied on the source code that you have received.
Let's back up for a moment just to make sure we're talking about the same "they." "They" being the author of this article, absolutely said almost verbatim what I claimed they said.
My post: "It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code"
The article: "This is tantamount to the addition of a term to the GPL prohibiting distribution or creating a penalty for distribution. GPL section 6 specifically prohibits any addition of terms."
>If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL.
Now it seems you're talking about GRsec and not the author of the article, but I definitely didn't claim GRsec said anything, I only made assertions about what the article said.
Then, going a step further, what you're arguing is yet another separate issue entirely, which is more relevant but still different than anything in this thread: Your claim is that their contract's rules of punishing someone for redistribution is not covered by GPL section 6. This may well be true, but I would personally guess not.
"You may not impose any further restrictions on the recipients' exercise of the rights granted herein" seems pretty clear cut to me. It implies that you can't impose any further restrictions. You can't even write a contract regarding the terms of redistributing GPLv2 software. And indeed, as far as I can tell, there's absolutely no precedence for being able to do that. If you could do that, then anyone could defeat the GPL by making a contract with sufficient punishment for redistribution.
While that may be true for Oracle (I doubt it), it's absolutely not true for Red Hat and SUSE. Not only are most of our projects developed in the open under free software licenses in the first place, we provide corresponding source for every package (regardless of the license terms, as long as it's a free software package) through our package manager as source RPMs.
The only restrictions that companies such as Red Hat and SUSE have is related to trademarks and distribution of the binaries that we compiled.
* Trademarks are a completely separate set of laws to copyright, and it has been long accepted in the free software community that as long as it is reasonably easy to remove trademark branding then this is acceptable (in Red Hat's and SUSE's cases, all branding is placed in separate and clearly marked packages -- so you can remove it by replacing those packages)[1].
* As for distribution of binaries, this policy exists for practical reasons and doesn't affect the community (the sources are available and we also provide an entire build service [Open Build Service[2]] that you can use directly to rebuild all of our sources and ISO images if you wished to).
openSUSE Leap is a community distribution created from the SLE sources. CentOS is similarly a distribution built from the RHEL sources.
[ I work for SUSE, and am also an FSF member -- I find spreading of misinformation like this incredibly harmful to the wider community. I would not work for SUSE if I felt that our actions were mistreating users. Opinions my own, obviously. ]
[1]: https://www.gnu.org/distros/free-system-distribution-guideli... [2]: https://build.opensuse.org/
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."
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?
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.
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.
[1] https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.12.xz
We detached this comment from https://news.ycombinator.com/item?id=14732721 and marked it off-topic.
> 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
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/ 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-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-ap...