GrSecurity Kernel Patches Will No Longer Be Free To The Public

[TheBlackCat]

TheBlackCat

They're kernel patches. They are derivative work of the Linux kernel.

Citation needed. A patch doesn't actually have to have any kernel code in it, and even if it does it may fall under an interoperability exception.

[Wilfred]

Yes upstream responded with break those patches up and resubmit.

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

Yes the kernel self protection project is being able to break up GrSecurity features and submit them interdependently. Yes they are not as well optimised as GrSecurity ones. Optimisation can come latter.

GrSecurity could be a jackass and not submit mainline while they did not have competition attempting to do the same things. You think about it you only have enough funds to either support GrSecurity or Kernel Self Protection Project. The Kernel Self Protection Project the fact it going up stream and peer reviewed its going to draw some peoples attention.

The price of not being at least partly mainline it left the door open to competition.

As spender has noted, there are lots of aslr breaks against the vanilla linux kernel to which grsecurity is not vulnerable.
I am inclined to believe that what is now upstreamed is not enough, and spender is right when he claims that the people upstreaming his patches do not understand them and how they interrelate.

[ssokolow]

Citation needed. A patch doesn't actually have to have any kernel code in it, and even if it does it may fall under an interoperability exception.

As I understand it, legal precedent basically paraphrases to "Patches are derived works because they aren't sufficiently useful without being applied to the base work."

[unixfan2001]

Citation needed. A patch doesn't actually have to have any kernel code in it, and even if it does it may fall under an interoperability exception.

You must be new to Linux...

Fact of the matter is: If something is being used to patch or link against the kernel, GPL suits and Linux developers consider it a derived work of the kernel.

The idea here is that, once compiled, it's all one binary so the free parts and the non-free parts collide.

Ditto for every GPLd library (with the exclusion of certain system libraries) being used by a client application. If product A links against library B (statically or dynamically, doesn't matter), they're considered to share the same context, thus product A is a derived work of library B.

[TheBlackCat]

As I understand it, legal precedent basically paraphrases to "Patches are derived works because they aren't sufficiently useful without being applied to the base work."

That is what I am asking for a citation for. If this is the legal precedent, there must be a court case establishing that precedent (by definition). I looked but wasn't able to find it.

[oiaohm]

As spender has noted, there are lots of aslr breaks against the vanilla linux kernel to which grsecurity is not vulnerable.
I am inclined to believe that what is now upstreamed is not enough, and spender is right when he claims that the people upstreaming his patches do not understand them and how they interrelate.

Really as you said spender there are a lot of aslr breaks most are 1 line patches in different locations to rectify. Of course you don't see spender doing that.

Interrelated is a huge excuse. Claiming interrelated means you cannot take the patch set apart and apply 1 feature at a time. For debugging multi platform.

Interrelated is a key one for mainlining. If patches are not mainline when mainline changes they can introduce security faults as well.

https://github.com/moby/moby/issues/20303

Now do you see the design fault here.

https://eigenstate.org/notes/seccomp

If you had read about seccomp sandboxing you would see the design fault.
chroot_deny_chmod and chroot_deny_mknod are system wide global things. So those patches as is going mainline in their current form are unlikely to be accepts.

Think for a case where you need 1 chroot with those features you have to disable the grsecurity feature for all the chroots you are using.

Seccomp jail can do the same job on a case by case.

The biggest security defect with grsecurity patches is that they are built on the design of total integrated solution with no allowance for people having to do limited rule breaking.

Upstream wants each feature from grsecurity to stand independently for very good reasons. The number of controls added to turn features globally on and off in grsecruity is a major fault.

Sorry allowing the interrelated excuse for not breaking up patches has to end. If the alteration can work by itself its not interrelated it is only an enhancement.

Really grsecurity supporting people need to stop throwing stones. Reality there are example after example of people having to over lower security to-do things with a grsecurity kernel because of too much of an all or nothing design.

[starshipeleven]

Problem is you only need to ask yourself a few basic questions.

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=160806

Grsecurity have been heavily x86 focused and are still very x86 focused.

https://kernsec.org/wiki/index.php/Feature_List

Notice mips, arm, arm64, powerpc . x86. KSPP is multi cpu coverage this is from working upstream to get stuff into mainline so putting the alterations in front of those dealing with other systems.

Can you please explain what this is supposed to mean?

waah waah grsecurity people don't want to make patches for other archs waah waah they are baaad waah waah.

They write stuff, they can decide to not care about archs they don't use/like/whatever. This isn't a proof of any wrongdoing, it's not breaking any rule.

https://forums.grsecurity.net/viewtopic.php?f=7&t=4476
If you want to see jackass read this carefully.
Update: shortly after this post, yet another kernel infoleak was posted. This particular one has been fixed already in grsecurity the same way since August of 2012.
So for 4 years grsecurity knows about a security fault and never sends to mainline.

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=31b0b385f69d8d5491a4bca288e25e63f1d945d0

Its a 2 line change. The grsecurity guys cannot point to where in 2012 they put a patch up to the Linux kernel and it was rejected. Because they never did.

You're reading that post wrong. The way they "fixed" the issue is by adding their system (PaX) that makes kernel infoleaks impossible to exploit even if there are known bugs as it randomizes kernel structures so any attacker can't know where to look to exploit them.

They didn't fix that specific infoleak and are not mainstreaming sources because they are somewhat evil, they prevented any infoleak with their own system even if they don't know where is the bug that caused the infoleak in the first place. You know what is supposed to do the KSPP? That's what it is supposed to do.
Does it do that? I see articles saying it does not fare that well, they are dug out by grsecurity, but the articles themselves are valid.

Lot of issues of grsecruity leaving people security exposed and them doing nothing to correct it.

They already left their code open for more than a decade, which is already more than what the GPL2 license required. What they are doing now isn't against GPL either.

Every time they get smart ass pointing out flaws you see a lot of fixes appear in the Linux kernel so meaning they cannot sell that as unique features any more.

Yes grsecruity are upset that other people are merging features they developed but they also never attempt to merge those features. So stiff you want credit you should have submitted your features mainline then someone else could not steal your thunder.

They don't want credit, they want money. Which isn't wrong per-se.

I really don't care of most of the waah waah you post, I need proof that what is in the kernel is decent enough.

[starshipeleven]

Actually no (not in this case): You'd be correct as far as GPLv3 is concerned - but with GPLv2 (and the Linux kernel is v2 only, not v2+) once you distribute a derived work, *everyone* is entiteled to receive the souce from you.
The situation gets less clear in case they provide only patches with no context to their customers.

https://www.gnu.org/licenses/gpl-2.0.html

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)


There is no requirement to share your source with anyone, only with those that receive a copy of it from you. So they only need to provide source code to customers to follow GPLv2 requirements.

The only license that requires that you send sources to more or less anyone is the AGPL (Affero GPL) that forces you to provide source of the AGPLed stuff on the server to any clients requesting it.

[ArchLinux]

IANAL, but I am pretty sure the patches are not automatically under the GPL. The GPL only applies to the source of software someone distributes. The patches themselves are not software, so they are the work of the company and can be under whatever license they want. I think the only situation where the patches would be under the GPL is if they are considered derivative works, but depending on the patch format there may be none of the original kernel code in them, and even if there was some there are some allowances to use portions of copyrighted works for the sake of interoperability (although those seem kind of fuzzy)

And that would mean that even if the company provided patched binaries, they wouldn't need to provide the actual stand-alone patches, although customers could reverse-engineer them by diffing the original sources with the patched ones (but they wouldn't be able to include the company patch descriptions or patch names).

Again, IANAL, but that is the impression I have gotten.

Your "impression" is missing the point there, as any patch that is based on a GPL source must also be GPL compatible. It's not "standalone" if it's a patch to a product, and not its own product.

Any subscribed customers could release the patches as they're required to distribute the source with any binaries…

I'm not sure if Grsecurity (and the whiny founder) have safeguarded against it, but you're not actually required to allow clients to distribute your changes - even as an entire tarball, as Red Hat does - if you have an additional agreement on top that by purchasing the software/subscription you as a customer acknowledge to relinquish that right.

This is an arrangement even the FSF has reviewed and approved upon, as that agreement is essentially a contract between two entities (client and vendor) that is not curtailed from overriding the GPL.

That's effectively BSD'ing (Bull-Shit Distributing?) GPL.

[TheBlackCat]

"Your impression" is missing the point there, as any patch that is based on a GPL source must also be GPL compatible. It's not "standalone" if it's a patch to a product, and not its own product.

It would be "compatible" in the legal sense if it forbids distributing of the patched software since the GPL rules only come into play when you distribute the software, unless the patch is a derivative work and thus also GPL-licensed by default. If you have a citation showing that a patch is a derivative work, please provide it. As I said, I wasn't able to find any reliable source one way or the other.