4 ms·

> Those get fixed. This has been done, but poorly and only for an extremely select few things. KASLR is just one example of a poorly implemented feature that p

by aseipp 10y ago

> Those get fixed. This has been done, but poorly and only for an extremely select few things. KASLR is just one example of a poorly implemented feature that pales in comparison to alternatives (completely subsumed by features in the grsec implementation, for example, since it only randomizes things like .text addresses. Maybe some of that got fixed.) Features like kptr_restrict can easily be subverted by a number of trivial infoleaks unless you back it up with a lot of other protections, etc. Other things like __ro_after_init for read-only post-init memory have only recently been incorporated into arch/x86 (in the past few months AFAICS, so likely kernel 4.8+ only) since being available for nearly a year on x86 at least. I'm not sure if they fixed the fact __ro_after_init apparently didn't work on loadable modules. grsecurity's implementation is better anyway (allowing remarking variables as writeable for short windows), but I'll concede that extra power relies on KERNEXEC, which breaks some userspace things. I don't think they botched the LATENT_ENTROPY plugin, at least... If you actually look at the details, Linux has a pretty bad track record as far as "meaningfully implementing defenses" goes, considering how long this stuff has been around. It's better than literally nothing, I guess. > There are places where the kernel could be further hardened, but would break software. Uhhhh, sorry, but you need to do your research. There are plenty of places that could be improved without breaking userland at all, while still mitigating many classes of exploits. PAX_REFCOUNT is one example (a variant of which will probably soon go upstream in some weird way, of course). RANDSTRUCT, PAX_MEMORY_STACKLEAK, KSTACKOVERFLOW, JIT_HARDEN, RAND_THREADSTACK... If you're determined to fix the FPs, the SIZE_OVERFLOW plugin qualifies, too (it occasionally hits false positives, murdering an otherwise legitimate task, but this is a different scenario to a feature outright breaking userspace, and it's caught many bugs and can stop many actual exploits on its own). There are probably at least a dozen major features in grsecurity that don't have to compromise userspace, and still aren't implemented in Linux, with no equivalent, and no timeline on the horizon. I'm not sure what to take away from this assessment of yours that the only remaining improvements will break things, other than you aren't really aware at all of what the current defense landscape looks like...

busterarm 10y ago
http://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel http://unix.stackexchange.com/questions/59020/why-are-the-gr...
- aseipp 10y ago
  That's a nice link. It also has absolutely zero to do with any of the specific defenses that I mentioned, and the fact that upstream Linux doesn't have them -- again, my point is there are tons of things upstream can still do to harden the kernel, before getting to breaking userspace, despite your initial claim to the contrary. The point isn't "you must adopt the grsecurity patches" or the politics around why grsec won't help upstream. The point is that these meaningful improvements actually exist, and they are not available. It's simply factual Linux is way behind what's possible. Furthermore, I really don't see how that link is relevant, given most of the more recent security features that went upstream, as well as many of the ones that will come in the future -- all originate in part from grsecurity anyway. Apparently, your position is that the kernel developers have already done all they can, and any further improvements else will break userspace, so systemd is definitely totes the #1 biggest problem now, everybody (non sequitur, but whatever). But when I bring up the defenses they could implement, but haven't yet, from the same source of the previous ones -- apparently I'm just doing some irrelevant posturing, or something? I find that funny. Maybe in 5 years when they've poorly ripped off more features and are still behind, you'll be moving the goalpost and saying "Any further improvements would break userspace", and it still won't be true in the slightest. :) PAX_REFCOUNT is a non-breaking addition that would have stopped CVE-2016-0728 completely, for example, had it actually existed upstream -- it will soon enough, at least, as someone is working on it by porting the grsecurity patches. The reality is very simple, even if you don't like it: upstream Linux is just bad at meaningful exploit mitigation, in many ways, and they have trailed behind what's possible for literally years. I'd also argue that some kernel developers seem to just have a complete, fundamental misunderstanding of what the point of the mitigations are, which is damning. One guy on the dev list argued with Kees Cook that people shouldn't bother with this shit, because we don't need to help "those bastards with proprietary modules be more secure" (Kees works on Android, so proprietary modules are just a fact of life, grsec improving their security simply being tangential), or help the people with out of tree kernels like the grsecurity team. It had apparently never dawned on him that mitigation tech could stop exploits that appear in the future. Like PAX_REFCOUNT stopping an exploit that would only appear in the future as time went on. This is mind-blowing as a position, for a developer of what is ostensibly one of the most complex projects in the world. Anyone who has followed the grsecurity project for a while is pretty well aware of why they don't bother with upstream, and aware that upstream mostly reinvents their work, poorly. In any case, the given link is still irrelevant. I'm going to go out on a limb and say you don't actually know much about modern memory corruption defense, or the landscape of modern kernel security and how it has moved forward over time, if this non-reply is your only answer to the examples I listed...

by aseipp 10y ago

busterarm 10y ago

http://unix.stackexchange.com/questions/59020/why-are-the-grsecurity-patches-not-included-in-the-vanilla-kernel http://unix.stackexchange.com/questions/59020/why-are-the-gr...

aseipp 10y ago
That's a nice link. It also has absolutely zero to do with any of the specific defenses that I mentioned, and the fact that upstream Linux doesn't have them -- again, my point is there are tons of things upstream can still do to harden the kernel, before getting to breaking userspace, despite your initial claim to the contrary. The point isn't "you must adopt the grsecurity patches" or the politics around why grsec won't help upstream. The point is that these meaningful improvements actually exist, and they are not available. It's simply factual Linux is way behind what's possible. Furthermore, I really don't see how that link is relevant, given most of the more recent security features that went upstream, as well as many of the ones that will come in the future -- all originate in part from grsecurity anyway. Apparently, your position is that the kernel developers have already done all they can, and any further improvements else will break userspace, so systemd is definitely totes the #1 biggest problem now, everybody (non sequitur, but whatever). But when I bring up the defenses they could implement, but haven't yet, from the same source of the previous ones -- apparently I'm just doing some irrelevant posturing, or something? I find that funny. Maybe in 5 years when they've poorly ripped off more features and are still behind, you'll be moving the goalpost and saying "Any further improvements would break userspace", and it still won't be true in the slightest. :) PAX_REFCOUNT is a non-breaking addition that would have stopped CVE-2016-0728 completely, for example, had it actually existed upstream -- it will soon enough, at least, as someone is working on it by porting the grsecurity patches. The reality is very simple, even if you don't like it: upstream Linux is just bad at meaningful exploit mitigation, in many ways, and they have trailed behind what's possible for literally years. I'd also argue that some kernel developers seem to just have a complete, fundamental misunderstanding of what the point of the mitigations are, which is damning. One guy on the dev list argued with Kees Cook that people shouldn't bother with this shit, because we don't need to help "those bastards with proprietary modules be more secure" (Kees works on Android, so proprietary modules are just a fact of life, grsec improving their security simply being tangential), or help the people with out of tree kernels like the grsecurity team. It had apparently never dawned on him that mitigation tech could stop exploits that appear in the future. Like PAX_REFCOUNT stopping an exploit that would only appear in the future as time went on. This is mind-blowing as a position, for a developer of what is ostensibly one of the most complex projects in the world. Anyone who has followed the grsecurity project for a while is pretty well aware of why they don't bother with upstream, and aware that upstream mostly reinvents their work, poorly. In any case, the given link is still irrelevant. I'm going to go out on a limb and say you don't actually know much about modern memory corruption defense, or the landscape of modern kernel security and how it has moved forward over time, if this non-reply is your only answer to the examples I listed...