1. 26
  1.  

  2. 7

    Word on the street is that grsec/PaX has had these issues solved for well over a decade.

    1. 5

      Prior work by high-assurance field in UCLA Secure UNIX, Trusted Xenix, etc showed UNIX was inherently insecure due to complexity and covert channels at API level. Nobody could even secure the Mach variants believably much less UNIX. Solution far back as LOCK program was a high-assurance microkernel designed for security with UNIX/Linux layer on top depriveleged. Security-critical components could run directly on microkernel optionally with safer languages. Done by many commercial RTOS’s, Nizza, Turaya Desktop, and recently GenodeOS.

      New attempts exist on doing it for monolith. These include Criswell et al’s SVA-OS + SAFEcode they ported Linux to, one that uses crypto on pages with compiler support, several that makes C memory-safe at CPU level, and CHERI that runs FreeBSD capability-secure. All but one (SVA) needs compiler modifications. So, as usual, work is already done, described in detail, and with some prototype code for people in FOSS to build on in rare event they ever try.

      I left off stuff like ExpressOS, JX, Redox, etc since it requires a rewrite in a non-C lamguage. We know where that goes…

      1. 5

        Microkernel anyone? Linus hates ‘em for some reason, but they really do make sense in this context.

        1. 3

          It’s the hornet’s nest that’s always worth revisiting.

          1. 3

            I still don’t get why he’s so salty about it. Apart from a slight memory overhead, and possibly a few other minor performance hits, microkernels seem to be better in almost every way. They’re also a more unix-y approach to kernel design, which is a plus, too.

            1. 12

              It’s complicated. The microkernel story of “oh, just restart” assumes all bugs manifest as discrete crashes, which isn’t really true. And then there’s the assumption that an attacker can compromise some component, but not leverage that. Like if I can pwn the file server, and it’s a device like a phone, full file system access may be all I’m after.

              If you’re interested, pick some Linux vulns, imagine what component they’d be in a microkernel, and then assess risk.

              1. 1

                That’s true, but it at least helps solve the problem of somewhat sandboxing crappy drivers so they can’t easily affect the rest of the system.

        2. 2

          Are there examples of Linux being looked at again and subsequently being changed in a major way?