5 ms·

I thought the same thing. The Linux kernel has been "freely available" for a measly 26 years, and will continue to be so.

by SEJeff 10y ago

qznc 10y 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 10y 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 10y 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 10y 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 10y 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.
      - SEJeff 10y ago
        Well I recall a somewhat recent case where you mentioned how there was one of features (I want to say it was the KASLR) that depended on another feature which still isn't in. You (spender in specific) mentioned on LWN how basically the feature was no good without the other 1/2 and the two changes were both somewhat invasive (in the Linux kernel context what Linus would consider invasive). I'm not saying you're wrong in any way or that you developed all 8+MB of code in 1 chunk. I'm saying you design your components to go together and depend on eachother, not to be split up individually and added sort of kind of willing/nilly. Did I get that wrong? From reading Brad on LWN for literally years wank about Linux security (he's absolutely not wrong to complain), this was my take. Or it could be summarized as (this is satire): PaxTeam: This is our code, it is open source, it is more secure than the dumpsterfire that is upstream, take it if you want it. Linux Upstream: That is nice, now break it into 1000 individual patches each independently git bisect-able. Also, can you change the interfaces of these design flaws in Linux and THEN entirely re-do your well tested patch to match the way we do code upstream and match the interfaces we would *like* Linux to have that we're going to expect you to code for us. PaxTeam: No, we want to do more interesting things like build more secure patches for Linux and look at pictures of cats on the internet, as it was designed to be used for. Linux Upstream: ...

I thought the same thing. The Linux kernel has been "freely available" for a measly 26 years, and will continue to be so.

by SEJeff 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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.
    - SEJeff 10y ago
      Well I recall a somewhat recent case where you mentioned how there was one of features (I want to say it was the KASLR) that depended on another feature which still isn't in. You (spender in specific) mentioned on LWN how basically the feature was no good without the other 1/2 and the two changes were both somewhat invasive (in the Linux kernel context what Linus would consider invasive). I'm not saying you're wrong in any way or that you developed all 8+MB of code in 1 chunk. I'm saying you design your components to go together and depend on eachother, not to be split up individually and added sort of kind of willing/nilly. Did I get that wrong? From reading Brad on LWN for literally years wank about Linux security (he's absolutely not wrong to complain), this was my take. Or it could be summarized as (this is satire): PaxTeam: This is our code, it is open source, it is more secure than the dumpsterfire that is upstream, take it if you want it. Linux Upstream: That is nice, now break it into 1000 individual patches each independently git bisect-able. Also, can you change the interfaces of these design flaws in Linux and THEN entirely re-do your well tested patch to match the way we do code upstream and match the interfaces we would *like* Linux to have that we're going to expect you to code for us. PaxTeam: No, we want to do more interesting things like build more secure patches for Linux and look at pictures of cats on the internet, as it was designed to be used for. Linux Upstream: ...