Announcement

Collapse
No announcement yet.

GrSecurity Kernel Patches Will No Longer Be Free To The Public

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by TheBlackCat View Post
    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.
    You need to look to German and USA court ruling in this. To not be a derivative the code has be able to function without the GPL work. Vmware case is tricky as vmware esxi can operate without the Linux kernel. Grsecurity without question does not function without the Linux kernel so fails the basic legal test so is a derivative work without question. Companies making routers have argued these points in USA and German courts and been told their code is GPL no matter how they slice the source code.

    These ruling do provide problems for those doing zfs drivers under Linux. Even a lot of closed source drivers are questionable.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by starshipeleven View Post
    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.
    It does in fact break a rule the Linux kernel includes a generic section for a reason. So large percentage of grsecurity is patched into the wrong section of the kernel tree since they were in x86 when they should have been in generic section. They have recently started to have to re-factor it. Part of the reason I see for them going closed to general public is avoiding have egg on face as they re-factor the patches showing they had been doing them wrong all the way along.

    When you are doing a modification to core of Linux kernel you are meant to seriously consider if it a generic alteration or a architecture particular alteration. Yes for years grsecurity team has taken the lazy way out and skipped doing this. It is one of the big differences with


    Originally posted by starshipeleven View Post
    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.
    No you did not read the bug right. Info leak bug is not prevent by KASLR of any form. It was only fixed by those 2 lines of alteration that was applied to mainline 4 years later than grsecurity and grsecurity got upset because they did not get credit.

    So that was a fault that should have been sent mainline.

    This particular one has been fixed already in grsecurity the same way since August of 2012
    The developer is very clear that the grsecurity patch set contained the exact same patch since 2012. He was upset that someone implemented the same thing and took credit. Its call parallel development. The one that took credit mainline never looked at grsecurity. So if he wants credit all the time for those little things better submit it mainline or live with miss out of credit.

    The way to beat kernel KASLR is exploit information leaks. The reality is not that mainline Linux kernel KASLR is defective yes as of 4.12 its going to be default on x86 kernels under Linux with other to follow.


    This is the paper grsecurity author references but does not provide link. PAX KASLR is just a weak to the attack as what mainline KASLR is. Also he goes on to claim that KASLR is worthless under arm64 even that it has been documented to block particular classes of bugs on Arm64. So this is more hey we have not managed to-do that so we will call it pointless instead of admitting they were beaten to the punch.

    KASLR weakness is if kernel memory information leaks the randomisation can be decoded and attack made functional.

    Originally posted by starshipeleven View Post
    They don't want credit, they want money. Which isn't wrong per-se.
    The grsecurity developers want both credit and money. The reality here is if you don't submit mainline expect at times to lose your credit it parallel development.

    Originally posted by starshipeleven View Post
    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.
    The grsecurity patches were not decent enough either. Kernel driver developers were not testing against grsecurity or design in information safe ways so there have been lots of security holes. You only need to follow when the Linux kernel blocked read/writing to userspace without using protection functions with how many drivers broke. Over half of those turned out to be exploitable information leaks that grsecuirty patches did not fix.

    The reality is grsecuirty has been attempting to put up a tent on quicksand. Lot of mainline work is required to make the kernel core stable to build on top of. The Linux kernel has been security quicksand and grsecurity guys have been fooling themselves and others that they could in fact fix it without doing the mainline work.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by ArchLinux View Post
    "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.

    Leave a comment:


  • ArchLinux
    replied
    Originally posted by TheBlackCat View Post
    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.

    Originally posted by peppercats View Post
    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.
    Last edited by ArchLinux; 21 May 2017, 06:42 AM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by W.Irrkopf View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by oiaohm View Post
    Problem is you only need to ask yourself a few basic questions.


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


    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.

    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Wilfred View Post
    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.

    I just hit almost the same issue as #14363 (mine reads "ApplyLayer exit status 1 stdout: stderr: chmod /bin/mount: permission denied") , also under Gentoo. It is related to the use of the kernels b...

    Now do you see the design fault here.

    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.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by ssokolow View Post

    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.

    Leave a comment:


  • unixfan2001
    replied
    Originally posted by TheBlackCat View Post

    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by TheBlackCat View Post

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

    Leave a comment:

Working...
X