Grsecurity: Potential contributory infringement and breach of contract risk

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.

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.

Out of curiosity, how did you determine that someone was trying to exploit you? And that the kernel crash was due to an attack?

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.

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.

Prove 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.

> 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.

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.

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.

They do not restrict you from distributing the source code.

Grsecurity restricts you from distributing the source code.

These are very different things.

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.

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

   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);

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