5 ms·

Yes, my first thought (after VMS) when he said no popular OS is designed for security. Then of course, I realized that by "Popular" he meant Mac OSX, Windows,

Yes, my first thought (after VMS) when he said no popular OS is designed for security. 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.

busterarm 10y ago
I don't think it's a fair statement to blame Linux's security problems on Linus. 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.
- this-dang-guy 10y ago
  Sure, but comments like: "Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them." "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.
  - busterarm 10y ago
    The market has sort of proved him right. 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.
    - this-dang-guy 10y ago
      Absolutely. I would actually argue that security doesn't depend on any one product, but instead a mindset, methodology, and toolbox. Defense in depth, etc.
- nickpsecurity 10y ago
  Of course it's fair. He built it to just have a person UNIX that he enjoys working on. Lots of other people did the same. Security was never a priority for them. Whereas, by that time, there were already multiple OS's with strong levels of built-in security. He could've copied stuff from them. There's even more now. They're still keeping broken model for (a) their priorities that put security low and (b) avoiding rewriting anything depending on broken security architecture. All the container developments are the classic solution to (b) but their security is often similarly shoddy vs what it could've been. 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. :)
  - busterarm 10y ago
    Right. I'm saying give up on expecting the project to change. The project isn't for what you want it to be for and never will be. 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 :)
    - this-dang-guy 10y ago
      I also use OpenBSD (and donate to it, since I have more money than time right now)... but damn, they do need a VM that I can use, so that it can be my regular desktop.
      - busterarm 10y ago
        QEMU too slow?
        this-dang-guy 10y ago
        Sadly yes. For several specific clients I have to run their Win7 VM in an emulator, and it can't quite manage on my (rather old) hardware right now. Due for a hardware refresh soon, and I will obviously be trying it again :)
- bonzini 10y ago
  What the hell does systemd have to do with kernel security issues? Is this Hacker News or slashdot?
  - busterarm 10y ago
    For the most part, they are not kernel security issues. 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.
    - 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

I don't think it's a fair statement to blame Linux's security problems on Linus. 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.

this-dang-guy 10y ago
Sure, but comments like: "Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them." "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.
- busterarm 10y ago
  The market has sort of proved him right. 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.
  - this-dang-guy 10y ago
    Absolutely. I would actually argue that security doesn't depend on any one product, but instead a mindset, methodology, and toolbox. Defense in depth, etc.
nickpsecurity 10y ago
Of course it's fair. He built it to just have a person UNIX that he enjoys working on. Lots of other people did the same. Security was never a priority for them. Whereas, by that time, there were already multiple OS's with strong levels of built-in security. He could've copied stuff from them. There's even more now. They're still keeping broken model for (a) their priorities that put security low and (b) avoiding rewriting anything depending on broken security architecture. All the container developments are the classic solution to (b) but their security is often similarly shoddy vs what it could've been. 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. :)
- busterarm 10y ago
  Right. I'm saying give up on expecting the project to change. The project isn't for what you want it to be for and never will be. 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 :)
  - this-dang-guy 10y ago
    I also use OpenBSD (and donate to it, since I have more money than time right now)... but damn, they do need a VM that I can use, so that it can be my regular desktop.
    - busterarm 10y ago
      QEMU too slow?
      - this-dang-guy 10y ago
        Sadly yes. For several specific clients I have to run their Win7 VM in an emulator, and it can't quite manage on my (rather old) hardware right now. Due for a hardware refresh soon, and I will obviously be trying it again :)
bonzini 10y ago
What the hell does systemd have to do with kernel security issues? Is this Hacker News or slashdot?
- busterarm 10y ago
  For the most part, they are not kernel security issues. 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.
  - 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...