"The whole idea of encapsulated data paths with labeled domains, etc. were all pioneered first in Solaris."
They actually came from the high assurance field that created the Orange and Red Books for endpoints and networking respectively. Earliest, fielded systems like that were in the mid-80's. Later, since nobody wanted real security, they dropped the assurance but kept & expanded features in so-called Compartmented Mode Workstations described here:
Others included Trusted IRIX, SEVMS version of OpenVMS, Trusted Xenix around same time as Sun MLS, and so on. Many of those weak OS's with security retrofits. Today, there's Argus Pitbull, Trustifier, maybe others I don't know about.
Over time, due to security failures, DOD once again wanted high assurance desktops built on secure isolation. Turned to separation kernels (MILS) built to high assurance requirements. INTEGRITY-178B, LynxSecure, and VxWorks MILS built on that model with labeled, color-defined, virtualized desktops showing up starting around 2005. Nizza security architecture and TUDOS demo did stuff similar to high-assurance work for OSS in 2005-2006. QubesOS showed up later building on insecure Xen stack w/ VM-level separation and CMW-like features. GenodeOS built on Nizza/TUDOS work around 2007 while continuing to integrate high-assurance stuff like seL4 where possible.
So, no, Sun didn't invent these concepts or even design a high assurance system that I'm aware of. It was SCOMP, GEMSOS, XTS-300, and likely Trusted Xenix that proved most of the concepts out. Sun copied and improved on a watered down version of that. Separation kernels like INTEGRITY-178B and architectures like Nizza showed how it was supposed to be done. Then, Qubes later copied CMW's w/ a weak virtualization scheme and components but better usability (administration & hardware support) than separation kernels.
Note I said pioneered, not invented, and the context is a desktop operating system.
Solaris contains the only surviving commercial implementation that I'm aware of that is still available and being updated and was last shipping in Solaris 11.3.
As far as I know, Solaris is also the last general (not tied to specific hardware), commercial UNIX.
Yes, we can nitpick all day about certification levels, but I never mentioned any of that.
"The whole idea of encapsulated data paths with labeled domains, etc. were all pioneered first in Solaris"
Your statement implies they came up with it, led the way, first to market... stuff like that. They didn't on any count. They did end up with highest market share for CMW's and so-called Trusted OS's. They were copycats on the important stuff, though. Not pioneers. They played it pretty safe.
"Solaris contains the only surviving commercial implementation that I'm aware of that is still available and being updated and was last shipping in Solaris 11.3."
RHEL w/ SELinux and security add-ons. Argus on Solaris and Linux. Trustifier on Linux. Seems like there's four on two OS's depending on your measurement.
"Yes, we can nitpick all day about certification levels, but I never mentioned any of that."
You definitely didn't. The product you referenced wouldn't have been on the evaluated products list on any high standard had you referenced one. It would also look like a knockoff of stuff before it with selective advances. Referencing certification levels or criteria would've defeated your point when people read what was in those. Smart move.
"They were copycats on the important stuff, though. Not pioneers. They played it pretty safe"
Copycats? You're going to resort to name calling in an attempt to discredit actual success and reality?
Name another commercial UNIX operating system today that has an equivalent to Solaris role-based access control fully integrated throughout the entire operating system and components, especially one that supports the "two-person" rule:
"RHEL w/ SELinux and security add-ons. Argus on Solaris and Linux. Trustifier on Linux. Seems like there's four on two OS's depending on your measurement."
RHEL isn't UNIX and their security model is nothing compared to Solaris.
"Smart move."
Apparently not as smart as quoting lots of facts not relevant to the given context (desktop operating system) and then dismissing decades of R&D and actual commercial success of Solaris in a snide manner.
"Copycats? You're going to resort to name calling in an attempt to discredit actual success and reality?"
We were talking about trusted extensions. Basically every feature they had came from Orange Book. CMW's like Trusted Solaris were watered down versions of high-security products like GEMSOS, XTS-300/400, and Boeing SNS Server. They had more features and prettier interfaces due to lack of rigor in implementation. Tons of 0-days but checked the right boxes. That with COTS push by DOD killed off high-security while letting crap like Trusted Solaris proliferate. Preventable 0-days and covert channels still abound in Solaris and Linux. Its market share was an accident of policy and economics combined.
"Name another commercial UNIX operating system today"
"Apparently not as smart as quoting lots of facts not relevant to the given context (desktop operating system) and then dismissing decades of R&D and actual commercial success of Solaris in a snide manner."
That's a different discussion than we were having about whether Trusted Solaris invented or pioneered the security concepts Qubes is implementing. It didn't for key concepts and wasn't even on list of high-security stuff. The best in CMW model is probably Argus's tech baked into either Solaris or RHEL. The best in UNIX/Linux is stuff coming out of CompSci where prototypes make BSD's or Linux immune to most code injections and/or leaks. The best in commercial are separation kernels that run Linux or POSIX apps untrusted with security-critical stuff on dedicated runtimes w/ secure middleware. The ideal would be a combo of that with CompSci stuff.
Unfortunately, Trusted OS's w/ huge amounts of kernel code are a broken model that never worked. I mean, they were known to be broken when CMW's were introduced as a compromise to get insecurity-loving OS users to adopts some features of high-security. It was bait. Solaris's risky, 0-day-filled TCB might be better than RHEL's or another's 0-day-filled TCB but that's a weak comparison if one wants low vulnerability, eh?
Far as commercial success, I you would similarly count (original) Windows NT process isolation and security architecture as more secure than Trusted Solaris due to "decades of R&D" from Microsoft and Microsoft's "actual commercial success." Heck, one had millions to tens of millions while the other had billions. Yet, I realize that's marketing and lock-in in action rather than $$$ made = better security. Actually, more money and market share usually means less security. Sad fact.
"Enjoy your pyrrhic victory"
We didn't win: low quality and security with high-lockin abounds. Expanded with web app silos. If anything, the mainstream OS's are getting pyrrhic victories for themselves at long-term expense in technical debt and damage to users.
> Edit: Also would it be possible for applications to enter into full screen mode?
No. If they could, then when they were told to full screen (or do so "automatically"), they could draw as convincingly as possible a Qubes-looking desktop and trick users into thinking it's their own desktop, allowing them to phish credentials and whatnot. The viability of this attack is low, but it can be avoided by not allowing full screen.
(Edit: Apparently I was wrong. It is possible to enable fullscreen manually, according to a sibling comment.)
Does anyone know if PCI passthrough works so we can play games inside a windows vm? Some user already asked this on the mailing list but got no answer. [1]
Qubes uses Xen and thus PCI passthrough for gaming can be made to work through the same procedures necessary for any other Xen+Linux OS.
But PCI passthrough for gaming isn't a great fit for the Qubes security model: it requires trusting that the Windows guest cannot compromise the GPU you loan it, which makes it a much bigger risk than an ordinary AppVM.
I thought the PCI passthrough security model assumes that the guest does compromise the GPU, and the guest-controlled GPU is isolated from the rest of the system using the IOMMU.
Do you mean these controls are porous by design or are you talking about bugs in the IOMMU protections?
First of all guest can easily update firmware on that device. As stated before GPUs are really complex devices and some part of them might be badly documented, like there is whole HDCP / DRM support that isn't documented at all. Of something like that happen you'll never find out.
Next time your PC going to boot your GPU will be initialized with host BIOS / UEFI long before kernel get possibility to limit it with IOMMU.
Interesting point. I hope this threat is something GPU vendors address, since secure virtualized GPU access has been a marketed feature for a while (at least from AMD). Quick googling drew a blank sadly.
Thanks for the answer, that's promising. Maybe I give it a try after investigating if my other hardware is supported (vt-d etc. is no problem, but it's not on the supported hardware list).
Yes, a dedicated machine for gaming would certainly be better. But I play only irregularly and games like Divinity: Original Sin, Pillars of Eternity etc. which I kind of trust to don't hijack the GPU.
It's not exactly about trusting the game. You'd be extending trust to... everything inside the VM you expose the graphics card to.
And graphics cards are messy. Many of them are frankly a lot like accessing main memory without an MMU. It's extremely easy to get scrapes of other application's video RAM that hasn't been zeroed.
I'm not trying to tell you you shouldn't do it of course. Just... be aware. "hijack the GPU" doesn't even require a whole lot of malice. I've had video memory of my firefox tabs from last shutdown draped across my screen while the lightdm login windows do their first paint, for example. This is just the world we live in :(
I really like the concept of Qubes. But they really need (imho) to work on their hardware compatibility list. I didn't investigate laptops much but last time I checked (2 or 3 months ago) they didn't have a fully supported (desktop) motherboard that can be bought new.
I tried to install it on my computer, it didn't work. I'd buy a new desktop just for Qubes if I had the guaranty that it would be fully supported. I'm not spending money just to discover that it won't run with my shiny new hardware.
I used it on my Thinkpad x220 and NUC 5th gen (BOXD54250WYKH) and it worked great. https://www.qubes-os.org/hcl/ - The HCL is pretty decent actually. But since they have to work on older Linux Kernel and Xen releases for stability/security and the hardware needs to have VT-d, TPM, HVM/VMX etc enabled - they will always be lagging in terms of the newer hardware they can support.
Might want to try out the BOXD54250WYKH1 NUC - Amazon is still selling it.
Maybe on the Titan, but I don't see it happen below that. I don't understand why AMD doesn't leverage this advantage. It's a niche market for consumers, but from my experience the people who are interested in this are often people who have more income than the average - which are customers that should be interesting to a company I would think.
I hate AMD cards. I've hated their linux support since I had the misfortune of owning an All-In-Wonder Radeon. I even refused to buy them around 2003, when I had too much abuse from ATI to keep using their hardware.
I just (today) made a purchase of a VM server off newegg, using all AMD hardware for hardware passthrough[0], because of how truly poor NVIDIA is in this regard.
Problem is that Nvidia refuse to support it for consumer GPUs. So you have to buy Quadro hardware if you need official support. They also introduced two "bugs" that make Windows drivers to fail on startup if KVM or Hyper-V enlightenments detected.
Currently there is way to bypass both "bugs", but they can introduce something new in newer version of drivers.
I remember reading a discussion a couple of years back where somebody wondered why Microsoft did not go a similar route for Windows. The original context was backwards compatibility with applications written for older releases of Windows.
But given the general security situation on Windows, it would be really nice to have, for example, the browser strongly isolated from the rest of the system.
The idea of using virtualization to enforce stronger isolation between different parts of the system seem like a good one, and it does not appear to be that non-obvious (of course, in hindsight so many things do).
Microsoft is doing all sorts of things for security. They added ways to remove privileges from apps, rolled out SDL reducing vulnerabilities tremendously, implemented Windows Integrity Controls with IE at lowest level, added EMET, added whitelisting, pushed managed code, started designing sandboxing schemes like Xax architecture, added a hypervisor (Hyper-V), did mathematical verification on it, and so on. I can easily say Microsoft is putting more work into security in their various layers than Linux/BSD, even OpenBSD in some ways.
Thing is, there's been third party solutions to handle virtualization-based security for Windows for anyone willing to buy them. People mostly don't. So, Microsoft rightly doesn't give a shit. It's why I tell people to use third-party enhancements if they rely on Windows or switch to Linux/BSD due to greater options for security not to mention what CompSci is cranking out for them.
> Microsoft is doing all sorts of things for security.
Indeed they are. Compared to Windows XP (pre-SP2), Windows has come an incredibly long way.
I just cannot help thinking that if they used virtualization the way Qubes OS does, they could both incrase isolation of applications and maintain backwards compatibility without having to jump through the countless hoops I imagine Windows developers must meet on a regular basis.
Hyper-V could be a very nice foundation for such an approach, at least in my fertile imagination. ;-)
Oh, I agree with that. It could be a benefit on top of what they have. A Dom0/hypervisor solution from them could actually be safer given they have tools for mathematically verifying both driver interactions and low-level system code. SLAM has been applied to drivers for years now. HyperV was verified with their VCC toolkit. So, they'd be a stronger than average foundation.
The best route for isolation, though, is to apply one of the industry separation kernels or virtualization schemes from CompSci that leave more untrusted. Good news is that I found a great document that describes MILS in detail plus some prior work and terms:
Pardon me, but I see a double negative in your last sentence. For clarification are you saying that "it does appear to be non-obvious" or as you wrote, "it does not appear to be non-obvious" (as in, it appears to be obvious)?
http://www.oracle.com/technetwork/articles/servers-storage-a...
https://en.wikipedia.org/wiki/Solaris_Trusted_Extensions
The whole idea of encapsulated data paths with labeled domains, etc. were all pioneered first in Solaris.
The unique spin here with Qubes OS seems to be do something similar, but using virtualization.