Thankfully, better designs such as seL4's VMM do exist, although it might need a little more work [1] until usable for the purpose.
https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/
Some exciting changes are coming:
https://www.qubes-os.org/news/2017/10/03/core3/
https://www.qubes-os.org/doc/releases/4.0/release-notes/
EDIT: Downvotes for providing relevant sources, really?
Sorry for not googling before asking...
Alternatively, consider not running a full-blown desktop or using Windows, which has grown a lot more secure since the Windows XP pre-SP2 days.
KVM is, like VMware, a Type 2 hypervisor. [1]
Xen is a proper Type 1 hypervisor.
[1] https://microkerneldude.wordpress.com/2010/10/14/much-ado-ab...
https://secure-os.org/pipermail/desktops/2015-November/00000...
Intel should be considered to be totally unreliable and incompetent.
I mean, no one buys office store safes and expects their things to be secure in them. But a processor is a little more expensive than a cheap safe and holds more valuable things.
Edit: and besides, Fortezza is an SSL protocol option.
https://groups.google.com/forum/m/#!topic/qubes-devel/jEe4pQ...
> It seems one major residing problem with KVM is the Linux kernel (which is large and vulnerable). A port of KVM to a thinner base layer would obviate those issues.
https://www.qubes-os.org/doc/certified-hardware/
Is anyone running this on a laptop? I get the feeling after reading that page that this is really strictly desktop only. Maybe the page has not been updated in a bit?
The closest you can get to Qubes on Windows would be to follow Microsoft's Privileged Access Workstation (PAW) guide, but it requires a lot of additional infrastructure[3]. That infrastructure allows you to do remote attestation of the virtual machines, but makes it costly to deploy in a SMB or homelab environment.
I don't expect it'll be very long before PAW and WDAG are usable at the same time, with colored window borders indicating the origin virtual machine. I hope this is on Microsoft's roadmap.
Video on privileged access workstation use, starting at a demo: https://youtu.be/3v8yQz2GWZw?t=41m48s
Video on privileged access workstation setup: https://www.youtube.com/watch?v=aPhfRTLXk_k
[1] https://docs.microsoft.com/en-us/windows/threat-protection/w...
[2] https://clearlinux.org/features/intel®-clear-containers
[3] https://docs.microsoft.com/en-us/windows-server/identity/sec...
[1] https://blog.invisiblethings.org/
[2] https://blog.invisiblethings.org/papers/2015/state_harmful.p...
[3] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
It's unmaintained now, but it is basically the same idea as WDAG. Essentially similar to firejail but the container gets its own lightweight kernel and runs in a stripped down VM, so the attack surface is KVM, not all parts of the kernel that aren't firewalled off by SECCOMP.
Considering the researchers who actually disabled IME require physical access to the machine[1], Purism's claim that they can do it to previously sold devices with only a software update[2] stinks of BS to me.
[1] https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Di...
[2] https://puri.sm/posts/purism-librem-laptops-completely-disab...
Tiny hypervisors like NOVA http://hypervisor.org, seL4-based are the ideal solution, but sadly no one seems to be pushing to make them usable and production-ready :(
This means that, if you use this OS on a laptop, you'll be vulnerable to cold-boot attacks, even after you close your lid, unless you configure it to shutdown on lid close. (I.e., if a highly skilled adversary steals your laptop then, even if your laptop lid is closed, they will be able to read your RAM and therefore decrypt your entire hard drive.)
Despite the major security implications, it doesn't sound like a fix will be implemented any time soon. [1]
Qubes' design means hardware and software are all separated so a vulnerability in one doesn't mean exposing another.
I like that in their docs they mention an approach they take and when it isn't secure[0]
That being said the main point of security contention is the admin (dom0).
https://blog.invisiblethings.org/papers/2015/state_harmful.p...
http://os.inf.tu-dresden.de/papers_ps/liebergeld-diplom.pdf
Complexity was still yoo high. Most in high-assurance security were trying stuff like Nova microhypervisor as a result. KVM on separation kernels might be worth further investigation for these platforms that will stay on KVM regardless.
I only just now downvoted you.
From [0]:
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
[1] https://puri.sm/shop/librem-13/ - see the Operating System choice
http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
http://www.crash-safe.org/papers.html
A more complex one is below that was also designed by one person for his dissertation. Knocks out all kinds of issues without modifying the processor. It has stuff to improve for sure but it think it proves the point pretty well. The stuff corporate teams were designing comes nowhere near this because they don't know much about high-security design. A critical part of that isn't features so much as a balancing act between what protection mechanisms do and don't that tries to minimize complexity to low as is possible.
https://theses.lib.vt.edu/theses/available/etd-10112006-2048...
And one open-source one on MIPS for capability-based security that runs FreeBSD:
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
A company or group of hardware volunteers could develop this into something at least as usable as a multi-core ARM CPU on RISC-V or OpenSPARC. It wouldn't take tons of money esp if they worked their way up in complexity. The hard stuff is already done. People just need to apply it. They could even pay these academics to do it for them with open-sourced results. They even get a huge discount on the EDA tools that can be six digits a seat.
You're right that Intel is screwing up and playing catchup cobbling together features. There was stuff in the available literature better than most of what they're doing. They even have a separation kernel from Wind River they're not employing. Managers without security expertise must be pushing a lot of this stuff.
Example, found through Qubes website: http://pete.akeo.ie/2011/06/crafting-bios-from-scratch.html
I have separate vms for media and browsing, for music (spotify), development (python, rust), skype, personal email, work email and password manager.
It needs 16gb of ram to be able to run all of these at once and about 150gb of disk if you actually create separate template vms.
My only real pain was coping and pasting between all of these vms (you need to ctrl+c then ctrl+shift+c for copy and the ctrl+shift+v, ctrl+v for paste [1])
I solved that with a custom solution that automatically distributes the clipboard contents (for text only) to multiple vms (depending on the source of the clipboard change). I know it defeats the purpose of isolation for the clipboard but it's ok for my use case.
This means you can run Genode on NOVA with VirtualBox 5 fully integrated as the VMM, all with the improved Noux/POSIX interop components in place, and have a decent package management solution (that handles API compatibilities, multiple version installs, src vs binary deps, packages, and more). There's also Xen support with the most recent release (for cloud appliance work with Genode)
What's more, based on the roadmap and challenges, they should be bringing VirtualBox5 support to the seL4 kernel, and they even have a goal for being the virtualization foundation of QubesOS. https://genode.org/about/challenges
With the recent toolchain update and new package management system, its easier than ever to cook up your own Genode-based systems.
In my own space, the approach has typically been to minimize attack surface by using the least amount of the simplest possible hardware we can get away with, then verifying the hell out of it. 8/16-bit micros, RS-232, no BIOS, aggressive shielding, and an extreme approach to the actor model. For things that need more horsepower, super-simple 32-bit micros, a real-time microkernel, and loads of QA. It's not perfect, and we leave a lot of performance on the table, but as far as security-per-man-hour-expended goes, I'd put it up against anything on the PC any day of the week.
nickpsecurity made a very good comment on designs circulating in the assurance/defense sectors: https://news.ycombinator.com/item?id=15571546
The best part of his comment was the quote from Brian Snow:
"The problem is innately difficult because from the beginning (ENIAC, 1944), due to the high cost of components, computers were built to share resources (memory, processors, buses, etc.). If you look for a one-word synopsis of computer design philosophy, it was and is sharing. In the security realm, the one word synopsis is separation: keeping the bad guys away from the good guys' stuff!
So today, making a computer secure requires imposing a "separation paradigm" on top of an architecture built to share. That is tough! Even when partially successful, the residual problem is going to be covert channels (i.e. side channels). We really need to focus on making a secure computer, not on making a computer secure -- the point of view changes your beginning assumptions and requirements."
Never said "Qubes sucks because it's not perfect." I have argued that the PC is too damn crufty and complicated to ever be "reasonably secure".
If I ever felt as though I had to protect myself from FBI[0] or ex-Mossad[1], I'd feel safer with an iPad and Signal than a PC running anything, and I say that as someone who doesn't particularly trust or care for Apple. You could also go full-Stallman[2], but that would probably be fairly error-prone if you didn't know as much about computers as RMS.
[0] https://www.theguardian.com/us-news/2015/may/12/revealed-fbi...
[1] https://www.newyorker.com/news/news-desk/harvey-weinsteins-a...
If you need a workstation that is hardened against the big boys, I doubt such a thing exists, and it never will if people keep putting all of their hope in the next band-aid. It is also a damn shame, since it's not like this is a problem that needs two more generations of pure science to solve.
Hell, the B5000[0] was safer than the things we run today, and people didn't stop having better ideas about computing in 1961.
a) tweak compilation flags of libraries & apps
b) describe full set of runtime config files of an app
and thus build a single full configuration of a whole system, like in NixOS.
Hm; or can this maybe somehow be solved with the "run scripts" mentioned at the end of the article? I'm even less than a noob with regards to Genode, so I'm not sure about that.
Or does the package manager only provide Nix-like functionality, with no way for NixOS-like features?