1. 18
  1.  

  2. 9

    Glad they’re progressing and improving UX. This…

    “based on the “Security by Compartmentalization” principle”

    …is remarketing of security terms. What they’ve actually built is a tiny subset of a Compartmented Mode Workstation (CMW) on top of the Multiple Independent Levels of Security (MILS) model w/ low-medium-assurance implementation. These are well-known concepts with tons of research into them and many commercial products. No need to reinvent terms. Interestingly, though, we saw the separation kernels certified as MILS rise around 2005, do great in pentesting, and ultimately be withdrawn as a central concept by NSA after isolation-only approaches didn’t prove out on Intel-style hardware that broke the model too much. Too many leaks and bypasses. Plus, you still have to have an extra component guarding information flows between security levels to enforce end-to-end security policy. Worked nicely in embedded systems, though.

    In any case, such a design can at least isolate untrustworthy code from many types of attacks if the TCB is high-assurance. The CMW’s were also good at preventing accidental leaks of secrets by casual users since they checked labels. Here’s examples of both for those curious.

    http://web.ornl.gov/~romeja/doecmw.pdf

    https://www.ghs.com/products/safety_critical/integrity-do-178b.html

    http://www.dtic.mil/get-tr-doc/pdf?AD=ADA480033

    Note: Notice the colorful windows of CMW’s with bottom-stripe to make them unspoofable. Privilege architecture also tries to stop things like password grabbing. Stuff on bottom-right of INTEGRITY-178B gives a glance at all the kinds of stuff one might have to look into to create a secure TCB for MILS system. The DTIC document is likely the formal verification of it since it was only one done through Common Criteria w/ formal proof in those years.

    1. 3

      I don’t think that the Qubes team has ever heard of SELinux. MILS is integrated into the sVirt solution specifically for isolating VM’s, but for some reason they absolutely refused to use KVM for almost that reason. The paravirtualization was always super off-putting to me, but the complete lack of doing prior-research bothers me far far more.

      1. 5

        I blasted them on the mailing list about not leveraging results of prior work. In that conversation, she didnt know about trusted paths, disagreed on Xen being security risk, didnt know benefits of user-mode drivers, and didn’t know about any of the competition that predated Qubes. She also countered my proposal to build on a security-focused microkernel saying Mac OS microkernel isnt secure. (Huh?)

        So, yeah, no confidence in that solution’s security. She later added trusted path and griped at Xen folks about their insecurity. No credit of course. ;) I relegated it to maybe a Linux hardening scheme with good usability. Still benefits to that for lay users.

        Note: Far as VMM’s, look up Nova microhypervisor’s design in the dissertation if you want to see the right kind of architecture for TCB reduction. Karger’s VAX VMM for security (esp layering).

        1. 2

          These are really great insights, Nick. Thank-you. I was looking forward to Qubes OS 4.0, but you’ve got me thinking deeper.

          Is Qubes OS providing a false sense of security, or does it still provide a genuine improvement over – say – running a standard Linux distribution with browsers in Firejail containers?

          1. 7

            I would take xen based security over linux cgroups or whatever in a heartbeat.

            1. 4

              I think in general you are accepting a certain degree of false sense of security when you are using Linux in general, it is not a high assurance operating system. I think Nick might agree that Linux is not a solution to the VMM layer and a better step might be to actually have an alternative that has formal methods for proofs or at the very least the VMM layer has formal methods. It was recently brought to my attention by Nick (thanks by the way) that the Xenon project exists just for the use case with Xen. I think if Qubes was dedicated to using Xen they would go after the Xenon project and attempt to get help from them to improve their stature instead of relying on solutions that have no strong guarentees.

              As for firejail I will point out that firejail is no more formally verifiable than Xen, in fact here is them fixing CVE-2016-7545. In my opinion it’s just a more fancy chroot, that doesn’t provide any leaps and bounds ahead in security improvements.

              Also as another piece of fuel for the fire just read this piece of documentation from the CubesOS team. Yes that is them actually suggesting to run everything as passwordless root sudo.

              In Qubes VMs there is no point in isolating the root account from the user account

              1. 2

                Re that last part: what’s actually wrong with letting an attacker have root in a VM where all interesting data is user-owned and fs changes aren’t persistent?

                1. 1

                  Due to memory loss, I can’t answer that question in detail for this use case. What I do remember is I’d never give anything root in a UNIX-based deployment due to the Principle of Least Privilege or Authority. That’s a security pattern that says every component gets as little access and ability as possible to do its job. This is especially important if specific privileges (i.e. root) have led to privilege escalations in the past due to sloppy coding, sloppy configuration, or complex interactions between components nobody saw coming. Matter of fact, one of main reasons for POLA is to block attacks you don’t see coming or increase odds of detection mid-attack as they try to pivot through the system.

                  So, it’s a bad idea in general. Anyone explaining why it’s safe when they give attackers a ladder toward the higher-hanging fruit is probably doing the wrong thing. Only time it’s sensible is when users demanded extra performance, features, integrations, or so on that made it absolutely necessary to add risk. Even then, better have a recovery strategy.

                  Fun version of Saltzer and Shroeder’s security principles:

                  http://emergentchaos.com/the-security-principles-of-saltzer-and-schroeder

              2. 1

                Xen w/ Dom0 is a smaller attack surface than the average Linux distro. Clean separation of activities into VM’s with that attack surface is an improvement over other designs. That’s why I recommend it as a hardening technique. The better options are unfortunately going to be commercial and pricey if they’ll even pick up the phone. Those use a tiny kernel at the bottom that’s designed for security with minimal components and attack surface. Alternatively, you might use an OS such as OpenBSD that at least does a lot of code review and mitigations. There’s Linux solutions like grsecurity or SELinux to provide extra protections but people tend to find lots of bugs in the privileged code of stuff like Linux.

                I always used and still recommend physical separation with controlled sharing. I used cheap, embedded computers behind a KVM. Each one was a different security level with at least one air-gapped with no way to communicate with other stuff. There’s a lot of manual, technical work in such a setup. Yet, the virtualized stuff usually had problems or was unaffordable to me. (shrugs)