Then of course, I realized that by "Popular" he meant Mac OSX, Windows, and Linux.
Linux of course, we all know is a security mess because Torvalds refuses to deal with security issues.
Linux provides support for lots of security options, but the project's guiding philosophy is "don't break userland". This is 99% of the time what you see Linus cursing out other kernel contributors for. All of the possible options that Linus could _enforce_ would do just that. Heck, a lot of the security problems and blame have nothing to do with the kernel at all and lie squarely with systemd and how it's implemented. If these are dealbreaker features that you must have, Linux is not the tool for you. Your efforts are better spent working to improve OpenBSD.
"So LSM stays in. No ifs, buts, maybes or anything else. When I see the security people making sane arguments and agreeing on something, that will change. Quite frankly, I expect hell to freeze over before that happens, and pigs will be nesting in trees. But hey, I can hope."
He's typically very critical of security-related changes unless they are a massive improvement. I think characterizing him as "functionality over security" is entirely fair. He's not even wrong necessarily.
Companies that use Linux and need security will either get caught with their pants down or they won't. It's up to their level of preparedness and luck. I wouldn't underwrite that if I were an insurer though.
Those of us that care are already using something else.
I would actually argue that security doesn't depend on any one product, but instead a mindset, methodology, and toolbox. Defense in depth, etc.
So, yeah, blame Linus and others in that ecosystem who do everything but make a solid foundation. Contrast that to OpenBSD for monolithic or GenodeOS for microkernel approaches where they bake security in at various levels. MINIX 3 for reliability levels they achieved 10x faster than monolithic UNIX's did. You get what you focus on. :)
You should be shouting at companies who use it for applications where security is a must. That's where the madness lies.
I use OpenBSD and so should you :)
Due for a hardware refresh soon, and I will obviously be trying it again :)
It's even possible to do modern web stuff on OpenBSD. Erlang and Elixir run on it, as does Postgres. Phoenix framework pretty much works out of the box.
Is this Hacker News or slashdot?
Those get fixed. There are places where the kernel could be further hardened, but would break software.
Most of the security issues that we talk about have to do with process permissions and runlevel. The runlevel of systemd and it's various components is actually my #1 security concern. Has nothing to do with the kernel.
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...
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...