5 ms·

That's a lot of trash-talking from someone who knows how to dish it but not take it: http://www.theregister.co.uk/2016/04/27/linux_security_bug_report_row/ htt

by jordigh 10y ago

That's a lot of trash-talking from someone who knows how to dish it but not take it: http://www.theregister.co.uk/2016/04/27/linux_security_bug_report_row/ http://www.theregister.co.uk/2016/04/27/linux_security_bug_r... I don't know who's right or wrong, but I wish Linux people (both sides) behaved more civilly. Linus breeds an atmosphere where personal attacks and insults are encouraged in the name of supposedly better code.

striking 10y ago
wrt link: Marcan's only crime was being a little cheeky. It didn't warrant the total meltdown/blockfest spender had. And on topic: Why can't the grsecurity patches just be merged into the kernel?
- GunboatDiplomat 10y ago
  My understanding is that it breaks things.
  - JoshTriplett 10y ago
    Quite a lot of things. The problem with grsecurity's claim that Linux doesn't care about security is that grsecurity doesn't appear to care about anything but security. They include changes with significant performance impact, changes that break existing userspace programs, and changes that significantly impact the maintainability of the kernel. Security that people can't or won't use doesn't actually make people more secure; usability, performance, compatibility, and other such concerns are all part of building a secure system. grsecurity has done a huge amount of innovation in kernel security, and they deserve quite a bit of credit for that. But grsecurity made a very public and vocal decision to no longer attempt to get any of that work into the upstream kernel, because they don't enjoy having to deal with the process involved in collaborative development. Instead, they went off and built a company around their out-of-tree work, and try to advocate that people use it. Meanwhile, some of the ideas that grsecurity pioneered (and a lot of other security innovations from other sources too) have started to make their way into the kernel, championed by people who are willing to do the work and participate in a collaborative development process. And the repeated response from grsecurity involves public whining, bashing of people doing the work they refuse to do, and, of course, advertisement. Whining that Linux doesn't have the security technology that they do seems rather hollow coming from people who very vocally gave up on doing the work to actually make Linux better. Out-of-tree, out-of-sight, out-of-mind.
    - viraptor 10y ago
      > Quite a lot of things. I don't think that's fair to say. grsec provides many things. Some are completely transparent once implemented, (readonly variables) some have performance impact, (uderef on 32bit) some (purposely) break existing behaviour. (forbidden MSR writes prevent energy management) You can pick and choose what you want. In practice on new hardware, I don't see any big drop in desktop environment.
      - geofft 10y ago
        But it also provides bugs, as demonstrated. (As another anecdote, at least as of many years ago, grsec + OpenAFS led to frequent deadlocks that never happened with a stock kernel.) Now of course Linux has tons of bugs too as does every nontrivial patchset being merged into Linux. But grsec has a preference for risking bugs that compromise functionality / uptime but not integrity. Linux upstream has exactly the opposite preference. On a desktop machine, a slightly increased risk to system availability is totally okay. On a server machine, it's a harder call, especially if the security benefit is only a defense-in-depth measure. For most servers out there, if they're running arbitrary code as an unprivileged user, something has already gone horribly wrong.
        viraptor 10y ago
        > But it also provides bugs, as demonstrated. I agree with it in general, but wouldn't go with the same conclusions. Upstream linux also sometimes results in random deadlocks and issues that people try to debug for weeks. That's what the rc cycle (6+ of them usually) is for. The unstabilities of grsec are kind of a side-effect of not many people looking at it. If this change happened on lkml, I'd bet someone would pick up the OpenAFS issue earlier. I don't think anyone from grsec team would be actively opposed to more users testing the releases.
- verroq 10y ago
  Because they have a patchset of thousands of lines and grsec has refused to break them up into parts so that they can be reviewed and patched in incrementally. Some of these patches in grsec are also controversial.
  - pbhjpbhj 10y ago
    Couldn't you accept the patch (for copyright purposes) then revert immediately. Then split the patch up and add it in piecemeal if desired - at least kernel programmers could use it if they wished then?
    - chris_wot 10y ago
      Why bother with the commit and then revert? Put it on a branch.
    - loeg 10y ago
      Why would you do that rather than just splitting the patch first?
    - gkya 10y ago
      Linux devs don't assign copyright, so if licenses are compatible they have to just take the patch and work on it.
- technion 10y ago
  I ran grsec on servers extensively for several years. This was several years ago so this information may be dated. It's not fair to discuss grsec as a whole, when asking "why hasn't it been merged?". The /tmp symlink protection was a personal pet peeve of mine for many years. As implemented by grsec, it completely eliminated an entire class of vulnerabilities. It also had zero overhead and was a very small patch. It frustrated me to no end that it took years to land in mainline. When it finally did, nothing broke (afaik). I can't understand at all the years of resistance. However, large parts of grsec were basically a competitor to SELinux. If you disagree with the assertion that selinux is fundamentally broken, then you have parts of grsec that don't belong in mainline. The chroot restrictions broke BIND on my installations, which happen to be one of the most commonly chroot() users in standard deployments. grsec has some great memory protection capabilities. There should at least be a conversation about some of this going mainline.
  - viraptor 10y ago
    > large parts of grsec were basically a competitor to SELinux. Why do you think so? RBAC is an optional part that requires extra configuration to even activate. There's a lot of benefit in running grsec kernel with SELinux as MAC. These features neither depend on RBAC nor even use it. It's kind of like smack, selinux, apparmor, yama, etc. You can think some of them are broken/worse than others. You're not forced to use them.
    - technion 10y ago
      I didn't suggest you were forced to use any feature. I just suggested that "this needs to be merged mainline" becomes cloudier for a certain feature that already has a similar implementation in mainline.
      - viraptor 10y ago
        I don't think anyone is realistically talking about merging the whole of grsec as it exists today. All the efforts and requests were always depending on splitting grsec into separate features that can be merged independently. RBAC feature could realistically be denied in favour of existing LSMs, while other features without equivalent solution could be included.
- geofft 10y ago
  > And on topic: Why can't the grsecurity patches just be merged into the kernel? Because even apart from straight-up bugs like the one being discussed, they are full of design decisions that fail in that direction, by design. Given the option between accidentally allowing malicious code to work and accidentally breaking benign software, Linux upstream prefers the former; grsec prefers the latter. For grsec it is better to have a kernel panic than an information disclosure, if those are your two options; for Linux upstream the preference is backwards. So if grsec is adding a safety option (in this case it was fundamentally caused by a check for integer overflow, IIRC, and getting things to work with that check), they're willing to risk breaking code and figuring it out later. LKML is willing to risk having the safety option not apply in all cases, but not risk breaking code that previously worked. Working through the stuff grsec provides and making sure it fits the LKML worldview (i.e., it only fails closed when the risk of false positives is sufficiently low or the admin has an option), both in design and implementation, is slow work. But it is happening.
- ashitlerferad 10y ago
  I don't think spender/PaXTeam want their stuff merged.

by jordigh 10y ago

striking 10y ago

wrt link: Marcan's only crime was being a little cheeky. It didn't warrant the total meltdown/blockfest spender had. And on topic: Why can't the grsecurity patches just be merged into the kernel?

GunboatDiplomat 10y ago
My understanding is that it breaks things.
- JoshTriplett 10y ago
  Quite a lot of things. The problem with grsecurity's claim that Linux doesn't care about security is that grsecurity doesn't appear to care about anything but security. They include changes with significant performance impact, changes that break existing userspace programs, and changes that significantly impact the maintainability of the kernel. Security that people can't or won't use doesn't actually make people more secure; usability, performance, compatibility, and other such concerns are all part of building a secure system. grsecurity has done a huge amount of innovation in kernel security, and they deserve quite a bit of credit for that. But grsecurity made a very public and vocal decision to no longer attempt to get any of that work into the upstream kernel, because they don't enjoy having to deal with the process involved in collaborative development. Instead, they went off and built a company around their out-of-tree work, and try to advocate that people use it. Meanwhile, some of the ideas that grsecurity pioneered (and a lot of other security innovations from other sources too) have started to make their way into the kernel, championed by people who are willing to do the work and participate in a collaborative development process. And the repeated response from grsecurity involves public whining, bashing of people doing the work they refuse to do, and, of course, advertisement. Whining that Linux doesn't have the security technology that they do seems rather hollow coming from people who very vocally gave up on doing the work to actually make Linux better. Out-of-tree, out-of-sight, out-of-mind.
  - viraptor 10y ago
    > Quite a lot of things. I don't think that's fair to say. grsec provides many things. Some are completely transparent once implemented, (readonly variables) some have performance impact, (uderef on 32bit) some (purposely) break existing behaviour. (forbidden MSR writes prevent energy management) You can pick and choose what you want. In practice on new hardware, I don't see any big drop in desktop environment.
    - geofft 10y ago
      But it also provides bugs, as demonstrated. (As another anecdote, at least as of many years ago, grsec + OpenAFS led to frequent deadlocks that never happened with a stock kernel.) Now of course Linux has tons of bugs too as does every nontrivial patchset being merged into Linux. But grsec has a preference for risking bugs that compromise functionality / uptime but not integrity. Linux upstream has exactly the opposite preference. On a desktop machine, a slightly increased risk to system availability is totally okay. On a server machine, it's a harder call, especially if the security benefit is only a defense-in-depth measure. For most servers out there, if they're running arbitrary code as an unprivileged user, something has already gone horribly wrong.
      - viraptor 10y ago
        > But it also provides bugs, as demonstrated. I agree with it in general, but wouldn't go with the same conclusions. Upstream linux also sometimes results in random deadlocks and issues that people try to debug for weeks. That's what the rc cycle (6+ of them usually) is for. The unstabilities of grsec are kind of a side-effect of not many people looking at it. If this change happened on lkml, I'd bet someone would pick up the OpenAFS issue earlier. I don't think anyone from grsec team would be actively opposed to more users testing the releases.
verroq 10y ago
Because they have a patchset of thousands of lines and grsec has refused to break them up into parts so that they can be reviewed and patched in incrementally. Some of these patches in grsec are also controversial.
- pbhjpbhj 10y ago
  Couldn't you accept the patch (for copyright purposes) then revert immediately. Then split the patch up and add it in piecemeal if desired - at least kernel programmers could use it if they wished then?
  - chris_wot 10y ago
    Why bother with the commit and then revert? Put it on a branch.
  - loeg 10y ago
    Why would you do that rather than just splitting the patch first?
  - gkya 10y ago
    Linux devs don't assign copyright, so if licenses are compatible they have to just take the patch and work on it.
technion 10y ago
I ran grsec on servers extensively for several years. This was several years ago so this information may be dated. It's not fair to discuss grsec as a whole, when asking "why hasn't it been merged?". The /tmp symlink protection was a personal pet peeve of mine for many years. As implemented by grsec, it completely eliminated an entire class of vulnerabilities. It also had zero overhead and was a very small patch. It frustrated me to no end that it took years to land in mainline. When it finally did, nothing broke (afaik). I can't understand at all the years of resistance. However, large parts of grsec were basically a competitor to SELinux. If you disagree with the assertion that selinux is fundamentally broken, then you have parts of grsec that don't belong in mainline. The chroot restrictions broke BIND on my installations, which happen to be one of the most commonly chroot() users in standard deployments. grsec has some great memory protection capabilities. There should at least be a conversation about some of this going mainline.
- viraptor 10y ago
  > large parts of grsec were basically a competitor to SELinux. Why do you think so? RBAC is an optional part that requires extra configuration to even activate. There's a lot of benefit in running grsec kernel with SELinux as MAC. These features neither depend on RBAC nor even use it. It's kind of like smack, selinux, apparmor, yama, etc. You can think some of them are broken/worse than others. You're not forced to use them.
  - technion 10y ago
    I didn't suggest you were forced to use any feature. I just suggested that "this needs to be merged mainline" becomes cloudier for a certain feature that already has a similar implementation in mainline.
    - viraptor 10y ago
      I don't think anyone is realistically talking about merging the whole of grsec as it exists today. All the efforts and requests were always depending on splitting grsec into separate features that can be merged independently. RBAC feature could realistically be denied in favour of existing LSMs, while other features without equivalent solution could be included.
geofft 10y ago
> And on topic: Why can't the grsecurity patches just be merged into the kernel? Because even apart from straight-up bugs like the one being discussed, they are full of design decisions that fail in that direction, by design. Given the option between accidentally allowing malicious code to work and accidentally breaking benign software, Linux upstream prefers the former; grsec prefers the latter. For grsec it is better to have a kernel panic than an information disclosure, if those are your two options; for Linux upstream the preference is backwards. So if grsec is adding a safety option (in this case it was fundamentally caused by a check for integer overflow, IIRC, and getting things to work with that check), they're willing to risk breaking code and figuring it out later. LKML is willing to risk having the safety option not apply in all cases, but not risk breaking code that previously worked. Working through the stuff grsec provides and making sure it fits the LKML worldview (i.e., it only fails closed when the risk of false positives is sufficiently low or the admin has an option), both in design and implementation, is slow work. But it is happening.
ashitlerferad 10y ago
I don't think spender/PaXTeam want their stuff merged.