5 ms·

Too bad Grsecurity isn't able to work together with upstream, their security knowledge seems to be legit.

by CorrectHorseBat 5y ago

staticassertion 5y ago
Alternatively phrased, too bad upstream isn't able to work with Grsecurity.
- throwawaylinux 5y ago
  grsecurity has a vested interest in having (or being seen to have) better security than upstream. Maybe upstream is able to work with hundreds of different and competing companies and thousands of different people and clashing personalities and opinions, but they just happen to irrationally refuse to treat grsecurity fairly. Or maybe it's the simpler explanation that has more obvious motives.
  - wahern 5y ago
    As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, especially after Spectre--Linus and a large part of the community were resistant to mitigations and code refactors that didn't actually add functional behavior, and especially if they were visible to userspace, harming backward compatibility. But those types of patches were precisely what grsecurity was pushing. So you basically had a fundamental clash of philosophies (independent of the clash of personalities) about whether the work grsecurity was doing was even valid from a software engineering standpoint. Arguably because of the relentless onslaught of exploits and growing enterprise influence, the Linux community slowly relented, but never with a mea culpa, AFAIK. A similar dynamic played out with /dev/urandom, where the Linux community and subsystem maintainers were adamant that the existing blocking and entropy accounting behaviors were crucial to security and non-negotiable. But now look where things stand--both are gone after 10-15+ years of debate. Again, without any mea culpas. Ditto for sandbox-friendly interfaces. Once upon a time any grievance that an interface which relied on /proc, /dev, or similar was suboptimal from a sandboxing standpoint (kernel surface area, headaches with chroots, etc) was met with derision. Eventually we got getrandom(2), and other recent application interfaces, like process descriptors, were revised so they were usable without /proc or similar. You could see alot of this play out on Slashdot, HN, etc as commenters frequently parroted Linux developers' talking points and assertions. There's plenty of blame to go around.
    - throwawaylinux 5y ago
      Many security mitigations have been merged into the kernel for a long time, probably longer than grsecurity has been around, but certainly something like NX-bit you could use as an example which was around the same time as early grsec (early 2000s). Sure Linus has been hostile or funny about such things at times, but that has not prevented him from being convinced or them from being merged.
  - staticassertion 5y ago
    Right, that's why they gave away their work for free for decades?
    - throwawaylinux 5y ago
      What's why?
      - staticassertion 5y ago
        You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. But Grsecurity made their patches freely available for the vast majority of their existence. I think it just shows ignorance of the situation to imply that they're only interested in making money.
        throwawaylinux 5y ago
        > You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. > But Grsecurity made their patches freely available for the vast majority of their existence. I didn't say anything about whether they made their patches freely available or not. Not sure what that has to do with what I wrote. > I think it just shows ignorance of the situation to imply that they're only interested in making money. I didn't imply that. I said they have a vested interest in perception of being more secure than upstream. Which they do. Replying with vague snark and going off on some wild tangent imagining things that I never implied isn't helpful if you can't address what I wrote. I didn't say anyone is to blame as such, nor does grsecurity have any requirement or moral duty to put effort into upstreaming their work. But if you look at the motivation there is a pretty reasonable explanation why they have not done so, in my opinion that's more reasonable and likely than the idea that it's upstream being particularly unfair or uncooperative to this one group.
nix23 5y ago
Too Bad Linus once called them Clowns [3]...but hey there's also [1] and [2] ;) 1: https://hardenedbsd.org/ https://hardenedbsd.org/ 2: https://www.openbsd.org/ https://www.openbsd.org/ 3: https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html 2008 (Linus): >>I think the OpenBSD crowd is a bunch of [self-stimulating] monkeys 2019 (Greg KH): >>OpenBSD was right on disabling hyper-threading
- loeg 5y ago
  HardenedBSD are clowns. OpenBSD has some good ideas, some clownish ideas, but as a user you cannot separate the two and as a developer community, they aren't interested in reducing the clown factor. GRSecurity also has some great ideas and some silly.
  - nix23 5y ago
    >HardenedBSD are clowns. Ahh that's why OPNsense uses it? But hey you write like a real professional in that field so i believe you, instead the people who actually work day in day out on a professional firewall product. Maybe you have to acknowledge that there is just one clown here ;)
    - loeg 5y ago
      I can't speak to OPNsense's judgment. I am a real professional in that field -- I've worked on FreeBSD in the past, and interacted with HBSD folks professionally.

Too bad Grsecurity isn't able to work together with upstream, their security knowledge seems to be legit.

staticassertion 5y ago

Alternatively phrased, too bad upstream isn't able to work with Grsecurity.

throwawaylinux 5y ago
grsecurity has a vested interest in having (or being seen to have) better security than upstream. Maybe upstream is able to work with hundreds of different and competing companies and thousands of different people and clashing personalities and opinions, but they just happen to irrationally refuse to treat grsecurity fairly. Or maybe it's the simpler explanation that has more obvious motives.
- wahern 5y ago
  As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, especially after Spectre--Linus and a large part of the community were resistant to mitigations and code refactors that didn't actually add functional behavior, and especially if they were visible to userspace, harming backward compatibility. But those types of patches were precisely what grsecurity was pushing. So you basically had a fundamental clash of philosophies (independent of the clash of personalities) about whether the work grsecurity was doing was even valid from a software engineering standpoint. Arguably because of the relentless onslaught of exploits and growing enterprise influence, the Linux community slowly relented, but never with a mea culpa, AFAIK. A similar dynamic played out with /dev/urandom, where the Linux community and subsystem maintainers were adamant that the existing blocking and entropy accounting behaviors were crucial to security and non-negotiable. But now look where things stand--both are gone after 10-15+ years of debate. Again, without any mea culpas. Ditto for sandbox-friendly interfaces. Once upon a time any grievance that an interface which relied on /proc, /dev, or similar was suboptimal from a sandboxing standpoint (kernel surface area, headaches with chroots, etc) was met with derision. Eventually we got getrandom(2), and other recent application interfaces, like process descriptors, were revised so they were usable without /proc or similar. You could see alot of this play out on Slashdot, HN, etc as commenters frequently parroted Linux developers' talking points and assertions. There's plenty of blame to go around.
  - throwawaylinux 5y ago
    Many security mitigations have been merged into the kernel for a long time, probably longer than grsecurity has been around, but certainly something like NX-bit you could use as an example which was around the same time as early grsec (early 2000s). Sure Linus has been hostile or funny about such things at times, but that has not prevented him from being convinced or them from being merged.
- staticassertion 5y ago
  Right, that's why they gave away their work for free for decades?
  - throwawaylinux 5y ago
    What's why?
    - staticassertion 5y ago
      You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. But Grsecurity made their patches freely available for the vast majority of their existence. I think it just shows ignorance of the situation to imply that they're only interested in making money.
      - throwawaylinux 5y ago
        > You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. > But Grsecurity made their patches freely available for the vast majority of their existence. I didn't say anything about whether they made their patches freely available or not. Not sure what that has to do with what I wrote. > I think it just shows ignorance of the situation to imply that they're only interested in making money. I didn't imply that. I said they have a vested interest in perception of being more secure than upstream. Which they do. Replying with vague snark and going off on some wild tangent imagining things that I never implied isn't helpful if you can't address what I wrote. I didn't say anyone is to blame as such, nor does grsecurity have any requirement or moral duty to put effort into upstreaming their work. But if you look at the motivation there is a pretty reasonable explanation why they have not done so, in my opinion that's more reasonable and likely than the idea that it's upstream being particularly unfair or uncooperative to this one group.

nix23 5y ago

Too Bad Linus once called them Clowns [3]...but hey there's also [1] and [2] ;) 1: https://hardenedbsd.org/ https://hardenedbsd.org/ 2: https://www.openbsd.org/ https://www.openbsd.org/ 3: https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html 2008 (Linus): >>I think the OpenBSD crowd is a bunch of [self-stimulating] monkeys 2019 (Greg KH): >>OpenBSD was right on disabling hyper-threading

loeg 5y ago
HardenedBSD are clowns. OpenBSD has some good ideas, some clownish ideas, but as a user you cannot separate the two and as a developer community, they aren't interested in reducing the clown factor. GRSecurity also has some great ideas and some silly.
- nix23 5y ago
  >HardenedBSD are clowns. Ahh that's why OPNsense uses it? But hey you write like a real professional in that field so i believe you, instead the people who actually work day in day out on a professional firewall product. Maybe you have to acknowledge that there is just one clown here ;)
  - loeg 5y ago
    I can't speak to OPNsense's judgment. I am a real professional in that field -- I've worked on FreeBSD in the past, and interacted with HBSD folks professionally.