11 ms·

Passing the Baton

93 points by albuic 9y ago

qznc 9y ago
Also read the corresponding FAQ: https://grsecurity.net/passing_the_baton_faq.php https://grsecurity.net/passing_the_baton_faq.php
admax88q 9y ago
I love how grsecurity is always quick to point out how generous they have been by providing the patches for free. > We have been providing grsecurity freely for 16 years. Meanwhile the kernel upon which their work is built has been provided for free for much longer, and continues to be.
- SEJeff 9y ago
  I thought the same thing. The Linux kernel has been "freely available" for a measly 26 years, and will continue to be so.
  - qznc 9y ago
    Why are the grsecurity patches not included in the Vanilla Kernel? https://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel https://unix.stackexchange.com/questions/59020/why-are-the-g...
    - pinpeliponni 9y ago
      Original discussion from over a decade ago was more about clashing opinions, strong personalities, and anti-NSA sentiment (how SELinux ws handled). Grsecurity has always been very opinionated, and technically well implemented. That has never been the issue. In theory they also could have chosen to maintain only one version - in the official kernel. To clarify some technical aspects, SELinux and grsecurity are not answers to the same problems, and they never meant to be. SELinux was always meant to implement things like multi-level security, bell-lapadula model, and extending 3rd party application with SeLinux roles, and the security daemon. Grsecurity has file oriented rbac system that was more approachable, and a variety of other patches (which are what grsecurity has been more known for - they have been always very excellent). Knowing Spender, he was probably actually paid to stop. That's my guess. Not going to iterate on that.
    - peterwwillis 9y ago
      In other words: nobody ever tried to get it into mainline. Anyone reading this right now could go and get it submitted into mainline in the chunks that Linus would accept. It would take about 6 months, though, assuming you knew what you were doing.
      - SEJeff 9y ago
        Incorrect, Kees Cook, who more or less founded the KSP project (kernel self protection) has been working on this for several years to enhance the security of ChromeOS while working for google. He started some of it when he was working for Canonical and has been doing this non-stop. The problem is that getting things into small individually testable components is literally anathema to the Pax/grsecurity model. They have very specific "chunks" of functionality which are quite invasive, by design. This goes against the model the Linux kernel is developed, so the two development communities are simply mutually exclusive. https://www.linux.com/news/google-developer-kees-cook-details-linux-kernel-self-protection-project https://www.linux.com/news/google-developer-kees-cook-detail... He's been working on this for a very long time.
        PaXTeam 9y ago
        > The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model. no, you're wrong. how do you think we developed our code? did all the 8+ MB worth of it pop out of our head all at once? or more realistically, did we develop the features piece by piece, not unlike how upstream linux is developed? > They have very specific "chunks" of functionality which are quite invasive, by design. define invasive. linux itself has 'quite invasive' features too yet that didn't prevent them from being developed and upstreamed, so not sure what you were trying to imply here. > This goes against the model the Linux kernel is developed, so the two development > communities are simply mutually exclusive. this narrative only exists in your head, not in reality. our work is as much upstreamable as any other kernel code that went in over the years (how else do you think some of it could get in already?), it's just that it can't be done in one's free time.
        9y ago
- tptacek 9y ago
  They have, in fact, been generous in providing patches for free. Other people have been generous too. Generosity doesn't cancel itself out. It must be particularly irritating in Spengler's case, because he works in a field where most of the best people make millions turning poorer versions of the same ideas into commercial products that only huge companies ever get to play with, while he spends his career arguing with upstream and taking shit from people on message boards.
  - qznc 9y ago
    Torvalds claims [0] that he did not do enough arguing with upstream: > The apparent inability (and perhaps more importantly - total unwilling[n]ess) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be merged. In a comment [0] the PAX team says > we never ever considered submitting grsecurity or PaX for mainline inclusion [...] anything similar in the past was user action, not on our behalf I don't know how Spengler and PAX relate. [0] https://lwn.net/Articles/313621/ https://lwn.net/Articles/313621/
    - lvh 9y ago
      PaX is developed independently from and usually shipped with grsec patches. AFAICT Spengler's not directly involved, and Torvald's comments don't reflect on them.
      - hackermailman 9y ago
        Every post on lwn or mailing lists by "PaXTeam" is quite obviously spender with another handle.
        PaXTeam 9y ago
        i think you're 'quite obviously' wrong ;).
        9y ago
- twiss 9y ago
  I think they're just tired of doing work and the kernel community going shrug (or worse, dismissing it). Of course, the kernel developers are also doing work for free, but at least their work is actually being accepted into the kernel. Maybe they're just thinking "our customers value our work, so let's focus on providing value to them instead of to people who don't value our work". Whether or not that's true, I don't blame them.
  - monocasa 9y ago
    > The important context here is that neither grsecurity nor PaX developers were involved in that mailing list discussion. The PaX Team's comment to the LWN article clears this up. We've never submitted the patches for mainline inclusion. https://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel https://unix.stackexchange.com/questions/59020/why-are-the-g...
  - tptacek 9y ago
    That is pretty much what Spengler says in the Stack Overflow question where this was asked directly.
    - cryptarch 9y ago
      Link for the lazy: https://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel https://unix.stackexchange.com/questions/59020/why-are-the-g...
- eugeneionesco 9y ago
  It's not just the patches they provided for, it's also innovation. The technologies these dudes developed are used in the vast majority of OSs outthere. Instead of posting a cynical comment here you should thank them.
  - monocasa 9y ago
    I mean, the grsecurity guys aren't the PAX guys.
    - eugeneionesco 9y ago
      They work together.
      - monocasa 9y ago
        We have no real evidence of that other than it's what Brad Spengler says.
        eugeneionesco 9y ago
        Are you serious? If yes, ask PAX Team, irc email, whatever.
        monocasa 9y ago
        You mean the freemail.hu email on a page that only appeared about a year after their last release?
        eugeneionesco 9y ago
        Please don't do that, this is not Reddit, I'm sure you'll figure a way out to contact PAX Team.
        monocasa 9y ago
- PaXTeam 9y ago
  you conveniently forgot to mention the fundamental difference: the upstream kernel isn't developed for free whereas our code has always been. changes the equation quite a bit, doesn't it?
  - cryptarch 9y ago
    What do you mean, the Linux kernel isn't developed for free? Many contributors aren't paid. And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?
    - PaXTeam 9y ago
      > What do you mean, the Linux kernel isn't developed for free? Many contributors aren't paid. you're wrong, see item 6 in https://opensource.com/article/16/12/yearbook-9-lessons-25-years-linux-kernel-development https://opensource.com/article/16/12/yearbook-9-lessons-25-y... though you might want to demand that Greg prove his identity first ;). > And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam? sure, come visit me in hungary and i'll take you to the local tax authorities and grant you access to my files. of course you'll have to prove your own identity first ;).
      - cryptarch 9y ago
        You mean that some developers are paid to implement things by companies? Fair enough, though I'd still argue it's not developed commercially because no one pays to get access to the result (they only pay to influence the result). >> sure, come visit me in hungary That'd be amusing, maybe sometime this summer? I'm kinda busy right now setting up my business :') Let me know when you're around the Benelux, we could do the key-siging song-and-dance over a coffee or beer.
  - cyphar 9y ago
    At most 80% of Linux contributors have jobs at software companies. That doesn't mean that all of them are paid for their kernel development, but at least 20% of contributors are definitely not paid for it. As for grsecurity, 100% of the core grsecurity team (that work at "Open Source Security") are paid for their work. I will admit that I'm not fully aware of the interactions between PaXTeam and grsecurity, but I'd be shocked to hear that nobody at PaXTeam works at a software company related to security or kernel hardening.
chamakits 9y ago
How does this work at a licensing level? GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the patches themselves being GPL?
- gbuk2013 9y ago
  Of course you can. https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainted-kernels.html https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte... Edit: --- Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject. A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applied to the source tree? On the other hand to generate a patch you would require the original source (even if you write it by hand you would still have to look at the source to determine line numbers). An you will probably have some bits of the source in your diff, but they are not being used for anything other than position information.
  - chamakits 9y ago
    Ah I see. So as long as they don't distribute the patch together with the GPL base codebase, they are good. Does that sound right?
    - peterwwillis 9y ago
      This only applies to LKMs which use non-GPLv2-only symbols. If you change half the kernel, you are creating a derivative work, and it is therefore GPLv2.
  - lvh 9y ago
    grsecurity's patch set is significantly more involved than a single module.
  - mrsteveman1 9y ago
    That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfront to remove the proprietary code and try to reproduce the bug again. End users can combine proprietary code with GPL code if they want to, because end users aren't bound by the GPL unless and until they distribute something covered by it. You don't even have to accept the terms of the GPL just to run the program[1]. A company distributing a proprietary module for the kernel may or may not be violating the GPL, depending on what it does and who you ask. In contrast to the module stuff, GRSecurity is a set of patches to very low level parts of the Linux kernel itself. It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. [1] https://www.gnu.org/licenses/gpl-2.0.en.html#section5 https://www.gnu.org/licenses/gpl-2.0.en.html#section5
mrsteveman1 9y ago
I suspect this will just shift focus to the Kernel Self Protection Project[1]. It may end up being the best thing that could have happened for kernel security in the end. [1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
- walterbell 9y ago
  Could KSPP evolve to add missing features that are currently present in grsecurity? https://grsecurity.net/compare.php https://grsecurity.net/compare.php
  - aseipp 9y ago
    If you're willing to wait a long time, then yes, KSPP, in years, might bring Linux kind-of on par with grsecurity today. If you mean in the short term, well... What will likely happen is people will base new features on the last public 4.9.x patches, the same way prior KSPP patches have been, such as PAX_REFCOUNT or the read-only static variables, latent entropy, etc. (Frankly most of these are uninteresting compared to the powerful things like RAP, UDEREF, size overflow, etc, and the patches were in some cases neutered in other ways -- but whatever.) However, grsecurity is more than that; if you watched the RSS feed, substantial amounts of effort went into also monitoring upstream kernels and carefully picking out security relevant commits and closing holes. The -stable grsecurity trees often had (literally) hundreds of included bugfixes that plugged things like minor infoleaks, 'benign' integer overflows, etc, when compared to the stable mainline kernels. (In fact, there were few better resources for getting a peek at security-sensitive code "in the wild" being analyzed and fixed than looking at the grsecurity RSS feed, IMO. Huge amounts of it was very enlightening to understand what kind of security sensitive issues you can find..) When a substantial amount of your infrastructure is about anti-memory corruption mitigations, taking care of stuff like infoleaks becomes more important. It is both the combination of all of grsecurity's features -- making most attacks substantially more difficult, or simply outright impossible in a lot of cases -- plus this kind of detailed attention -- not just stopping whole techniques, but also mitigating future possible attacks -- that put it very far ahead of the competition. It is not just a patch set, it is also very much a mind set, and a development model, behind the system. In short, I don't agree this is the best thing that could happen for Linux Security or the KSPP. It's one of the worst, in fact. I think it means the KSPP will fall even further behind grsecurity as it will now develop all of its new protections privately (such as the whispered KERNSEAL), and they will be left to their own devices to develop new protections. (The current grsecurity authors have over a decade of experience in advanced anti-corruption techniques and kernel hardening, you're already starting the race late.) And even if they do rip the code out of the old kernels, and they do manage to keep it in tact without neutering or removing parts, it's not clear to me the kernels will still have the level of attention or mindset previously seen by the grsecurity team, which means it will overall still be worse off. I knew this was coming after the -stable trees were pulled. It sucks.
amluto 9y ago
This outcome makes me kind of sad. I bet there would be people willing to fund development of grsecurity and PaX in the open (i.e. with broken out patches, etc.), and there could plausibly be more money in that than in selling subscriptions.
zkms 9y ago
the FAQ mentions "KERNSEAL, STRUCTGUARD" -- what are these? I tried searching on google but didn't find anything about either.

93 points by albuic 9y ago

qznc 9y ago

Also read the corresponding FAQ: https://grsecurity.net/passing_the_baton_faq.php https://grsecurity.net/passing_the_baton_faq.php

admax88q 9y ago

I love how grsecurity is always quick to point out how generous they have been by providing the patches for free. > We have been providing grsecurity freely for 16 years. Meanwhile the kernel upon which their work is built has been provided for free for much longer, and continues to be.

SEJeff 9y ago
I thought the same thing. The Linux kernel has been "freely available" for a measly 26 years, and will continue to be so.
- qznc 9y ago
  Why are the grsecurity patches not included in the Vanilla Kernel? https://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel https://unix.stackexchange.com/questions/59020/why-are-the-g...
  - pinpeliponni 9y ago
    Original discussion from over a decade ago was more about clashing opinions, strong personalities, and anti-NSA sentiment (how SELinux ws handled). Grsecurity has always been very opinionated, and technically well implemented. That has never been the issue. In theory they also could have chosen to maintain only one version - in the official kernel. To clarify some technical aspects, SELinux and grsecurity are not answers to the same problems, and they never meant to be. SELinux was always meant to implement things like multi-level security, bell-lapadula model, and extending 3rd party application with SeLinux roles, and the security daemon. Grsecurity has file oriented rbac system that was more approachable, and a variety of other patches (which are what grsecurity has been more known for - they have been always very excellent). Knowing Spender, he was probably actually paid to stop. That's my guess. Not going to iterate on that.
  - peterwwillis 9y ago
    In other words: nobody ever tried to get it into mainline. Anyone reading this right now could go and get it submitted into mainline in the chunks that Linus would accept. It would take about 6 months, though, assuming you knew what you were doing.
    - SEJeff 9y ago
      Incorrect, Kees Cook, who more or less founded the KSP project (kernel self protection) has been working on this for several years to enhance the security of ChromeOS while working for google. He started some of it when he was working for Canonical and has been doing this non-stop. The problem is that getting things into small individually testable components is literally anathema to the Pax/grsecurity model. They have very specific "chunks" of functionality which are quite invasive, by design. This goes against the model the Linux kernel is developed, so the two development communities are simply mutually exclusive. https://www.linux.com/news/google-developer-kees-cook-details-linux-kernel-self-protection-project https://www.linux.com/news/google-developer-kees-cook-detail... He's been working on this for a very long time.
      - PaXTeam 9y ago
        > The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model. no, you're wrong. how do you think we developed our code? did all the 8+ MB worth of it pop out of our head all at once? or more realistically, did we develop the features piece by piece, not unlike how upstream linux is developed? > They have very specific "chunks" of functionality which are quite invasive, by design. define invasive. linux itself has 'quite invasive' features too yet that didn't prevent them from being developed and upstreamed, so not sure what you were trying to imply here. > This goes against the model the Linux kernel is developed, so the two development > communities are simply mutually exclusive. this narrative only exists in your head, not in reality. our work is as much upstreamable as any other kernel code that went in over the years (how else do you think some of it could get in already?), it's just that it can't be done in one's free time.
        9y ago
tptacek 9y ago
They have, in fact, been generous in providing patches for free. Other people have been generous too. Generosity doesn't cancel itself out. It must be particularly irritating in Spengler's case, because he works in a field where most of the best people make millions turning poorer versions of the same ideas into commercial products that only huge companies ever get to play with, while he spends his career arguing with upstream and taking shit from people on message boards.
- qznc 9y ago
  Torvalds claims [0] that he did not do enough arguing with upstream: > The apparent inability (and perhaps more importantly - total unwilling[n]ess) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be merged. In a comment [0] the PAX team says > we never ever considered submitting grsecurity or PaX for mainline inclusion [...] anything similar in the past was user action, not on our behalf I don't know how Spengler and PAX relate. [0] https://lwn.net/Articles/313621/ https://lwn.net/Articles/313621/
  - lvh 9y ago
    PaX is developed independently from and usually shipped with grsec patches. AFAICT Spengler's not directly involved, and Torvald's comments don't reflect on them.
    - hackermailman 9y ago
      Every post on lwn or mailing lists by "PaXTeam" is quite obviously spender with another handle.
      - PaXTeam 9y ago
        i think you're 'quite obviously' wrong ;).
      - 9y ago
twiss 9y ago
I think they're just tired of doing work and the kernel community going shrug (or worse, dismissing it). Of course, the kernel developers are also doing work for free, but at least their work is actually being accepted into the kernel. Maybe they're just thinking "our customers value our work, so let's focus on providing value to them instead of to people who don't value our work". Whether or not that's true, I don't blame them.
- monocasa 9y ago
  > The important context here is that neither grsecurity nor PaX developers were involved in that mailing list discussion. The PaX Team's comment to the LWN article clears this up. We've never submitted the patches for mainline inclusion. https://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel https://unix.stackexchange.com/questions/59020/why-are-the-g...
- tptacek 9y ago
  That is pretty much what Spengler says in the Stack Overflow question where this was asked directly.
  - cryptarch 9y ago
    Link for the lazy: https://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel https://unix.stackexchange.com/questions/59020/why-are-the-g...
eugeneionesco 9y ago
It's not just the patches they provided for, it's also innovation. The technologies these dudes developed are used in the vast majority of OSs outthere. Instead of posting a cynical comment here you should thank them.
- monocasa 9y ago
  I mean, the grsecurity guys aren't the PAX guys.
  - eugeneionesco 9y ago
    They work together.
    - monocasa 9y ago
      We have no real evidence of that other than it's what Brad Spengler says.
      - eugeneionesco 9y ago
        Are you serious? If yes, ask PAX Team, irc email, whatever.
        monocasa 9y ago
        You mean the freemail.hu email on a page that only appeared about a year after their last release?
        eugeneionesco 9y ago
        Please don't do that, this is not Reddit, I'm sure you'll figure a way out to contact PAX Team.
        monocasa 9y ago
PaXTeam 9y ago
you conveniently forgot to mention the fundamental difference: the upstream kernel isn't developed for free whereas our code has always been. changes the equation quite a bit, doesn't it?
- cryptarch 9y ago
  What do you mean, the Linux kernel isn't developed for free? Many contributors aren't paid. And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?
  - PaXTeam 9y ago
    > What do you mean, the Linux kernel isn't developed for free? Many contributors aren't paid. you're wrong, see item 6 in https://opensource.com/article/16/12/yearbook-9-lessons-25-years-linux-kernel-development https://opensource.com/article/16/12/yearbook-9-lessons-25-y... though you might want to demand that Greg prove his identity first ;). > And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam? sure, come visit me in hungary and i'll take you to the local tax authorities and grant you access to my files. of course you'll have to prove your own identity first ;).
    - cryptarch 9y ago
      You mean that some developers are paid to implement things by companies? Fair enough, though I'd still argue it's not developed commercially because no one pays to get access to the result (they only pay to influence the result). >> sure, come visit me in hungary That'd be amusing, maybe sometime this summer? I'm kinda busy right now setting up my business :') Let me know when you're around the Benelux, we could do the key-siging song-and-dance over a coffee or beer.
- cyphar 9y ago
  At most 80% of Linux contributors have jobs at software companies. That doesn't mean that all of them are paid for their kernel development, but at least 20% of contributors are definitely not paid for it. As for grsecurity, 100% of the core grsecurity team (that work at "Open Source Security") are paid for their work. I will admit that I'm not fully aware of the interactions between PaXTeam and grsecurity, but I'd be shocked to hear that nobody at PaXTeam works at a software company related to security or kernel hardening.

chamakits 9y ago

How does this work at a licensing level? GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the patches themselves being GPL?

gbuk2013 9y ago
Of course you can. https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainted-kernels.html https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte... Edit: --- Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject. A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applied to the source tree? On the other hand to generate a patch you would require the original source (even if you write it by hand you would still have to look at the source to determine line numbers). An you will probably have some bits of the source in your diff, but they are not being used for anything other than position information.
- chamakits 9y ago
  Ah I see. So as long as they don't distribute the patch together with the GPL base codebase, they are good. Does that sound right?
  - peterwwillis 9y ago
    This only applies to LKMs which use non-GPLv2-only symbols. If you change half the kernel, you are creating a derivative work, and it is therefore GPLv2.
- lvh 9y ago
  grsecurity's patch set is significantly more involved than a single module.
- mrsteveman1 9y ago
  That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfront to remove the proprietary code and try to reproduce the bug again. End users can combine proprietary code with GPL code if they want to, because end users aren't bound by the GPL unless and until they distribute something covered by it. You don't even have to accept the terms of the GPL just to run the program[1]. A company distributing a proprietary module for the kernel may or may not be violating the GPL, depending on what it does and who you ask. In contrast to the module stuff, GRSecurity is a set of patches to very low level parts of the Linux kernel itself. It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. [1] https://www.gnu.org/licenses/gpl-2.0.en.html#section5 https://www.gnu.org/licenses/gpl-2.0.en.html#section5

mrsteveman1 9y ago

I suspect this will just shift focus to the Kernel Self Protection Project[1]. It may end up being the best thing that could have happened for kernel security in the end. [1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

walterbell 9y ago
Could KSPP evolve to add missing features that are currently present in grsecurity? https://grsecurity.net/compare.php https://grsecurity.net/compare.php
- aseipp 9y ago
  If you're willing to wait a long time, then yes, KSPP, in years, might bring Linux kind-of on par with grsecurity today. If you mean in the short term, well... What will likely happen is people will base new features on the last public 4.9.x patches, the same way prior KSPP patches have been, such as PAX_REFCOUNT or the read-only static variables, latent entropy, etc. (Frankly most of these are uninteresting compared to the powerful things like RAP, UDEREF, size overflow, etc, and the patches were in some cases neutered in other ways -- but whatever.) However, grsecurity is more than that; if you watched the RSS feed, substantial amounts of effort went into also monitoring upstream kernels and carefully picking out security relevant commits and closing holes. The -stable grsecurity trees often had (literally) hundreds of included bugfixes that plugged things like minor infoleaks, 'benign' integer overflows, etc, when compared to the stable mainline kernels. (In fact, there were few better resources for getting a peek at security-sensitive code "in the wild" being analyzed and fixed than looking at the grsecurity RSS feed, IMO. Huge amounts of it was very enlightening to understand what kind of security sensitive issues you can find..) When a substantial amount of your infrastructure is about anti-memory corruption mitigations, taking care of stuff like infoleaks becomes more important. It is both the combination of all of grsecurity's features -- making most attacks substantially more difficult, or simply outright impossible in a lot of cases -- plus this kind of detailed attention -- not just stopping whole techniques, but also mitigating future possible attacks -- that put it very far ahead of the competition. It is not just a patch set, it is also very much a mind set, and a development model, behind the system. In short, I don't agree this is the best thing that could happen for Linux Security or the KSPP. It's one of the worst, in fact. I think it means the KSPP will fall even further behind grsecurity as it will now develop all of its new protections privately (such as the whispered KERNSEAL), and they will be left to their own devices to develop new protections. (The current grsecurity authors have over a decade of experience in advanced anti-corruption techniques and kernel hardening, you're already starting the race late.) And even if they do rip the code out of the old kernels, and they do manage to keep it in tact without neutering or removing parts, it's not clear to me the kernels will still have the level of attention or mindset previously seen by the grsecurity team, which means it will overall still be worse off. I knew this was coming after the -stable trees were pulled. It sucks.

amluto 9y ago

This outcome makes me kind of sad. I bet there would be people willing to fund development of grsecurity and PaX in the open (i.e. with broken out patches, etc.), and there could plausibly be more money in that than in selling subscriptions.

zkms 9y ago

the FAQ mentions "KERNSEAL, STRUCTGUARD" -- what are these? I tried searching on google but didn't find anything about either.