Hacker News new | more | comments | ask | show | jobs | submit login
Qubes OS: A reasonably secure operating system (qubes-os.org)
441 points by ploggingdev on Nov 19, 2017 | hide | past | web | favorite | 144 comments

Joanna's (Qubes OS Founder) blog [1] is a gold mine when it comes to hardware-software boundary security. Especially "State considered harmful" [2] and "x86 considered harmful" [3] papers are eye-openers.

[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

Apparently she wants to move state to another device that is portable?

I think realistically state is hard to avoid unless you are using disposable read-only memory.

I think the Qubes website is also quite useful for informational purposes.

Example, found through Qubes website: http://pete.akeo.ie/2011/06/crafting-bios-from-scratch.html

That's why I don't get Qubes. She knows what a steaming pile PC hardware is, and decides to write a spinoff OS for it???

Seems like she'd have more effect designing hardware.

I believe I remember reading she aims at solving the issue of hardware and software vulnerabilities. I can't find the source, but she mentions that there's too much code out there that it would be impossible to secure everything.

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).

[0]: https://www.qubes-os.org/doc/copy-paste/

But those two things are not independent. If your hardware is fundamentally broken, hypervisors can only paper over so much.

Between the twilight of Moore's law, and the success of open-source software, I just don't see that much long-term value left in x86+PC.

It is a lot easier to do the best you can with tech that exists. Building a completly new type of computer and and OS is not easy.

She is working on hardware but that is not as easy to bring into the wider world.

Q: Would the steaming pile be stinkier with an easy way to deploy & use VMs to separate things, or without?

A: Stinkier without, therefore Qubes.

That's assuming the virtualization extensions are doing their job, and the other parts of the processor aren't leaking anything, and that Xen doesn't have any problems, and that the Qubes additions are solid, and that various interactions between these layers won't present any other problems, and probably a few other things...

I'd consider betting on one of those things being solid on its own, but not all of them together.

Old Thing has issues with X, Y and Z.

New Thing solves X and Y but not Z.

Therefore, criticize New Thing for not solving Z.

No. I'm mostly just chafed when anything for something as overcomplicated as a PC gets marketed as "secure" or "reasonably secure". Sure, most of the HN crowd knows the ins and outs, but a lot of end users don't.

I run into so many people at local interest groups who do less than advisable things on the computer, yet don't even give a second thought to it because "I'm using Tails!" Or "I'm using Qubes!"

At the same time, I have friends who do security for the military who show and tell so many different (and simple) ways to exfiltrate data that bypass most of the hypervisor/os/software stack.

This is a better condom. That is an accomplishment, and I tip my hat to them. At the same time, if you really don't want the diseases, it's safest to just stay off tindr.

Well it obviously doesn't compete with whatever you're currently doing that solves all the same problems perfectly.

Why does it have to get personal rdiddly?

If you've spent any time with Intel's phone-book-sized opcode manual, or following the history of the PC, you get real skeptical when the words "secure" and "PC" are mentioned together.

He's not getting personal. You're being a bit unreasonable.

Why are you pointing the finger at Qubes for not solving every problem there is? It's doing a much better job than ~every other Linux distro.

Apologies for the sarcasm, really I'm just wondering what you're using then. To me there's no "secure" and "insecure," there's only "more secure" and "less secure."

PC x86 architecture (including the Mac), for at least the past 20 years, has been cost-optimized as a games/performance machine, not a security one. Until that changes, the more/less secure axis is always going to be heavily biased towards "less" on the PC, regardless of what you run on top of it.

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."

That's great you have a design for something much more secure, but what are you actually using at the moment?

I agree Qubes (or other similar systems) are imperfect - partly due to software bugs, partly due to hardware vulnerabilities. But the it clearly is an improvement, if only thanks to the compartmentalization. I'm sure there are potential adversaries that have access to BIOS backdoors, Xen 0-days etc. But well ...

Already answered that above.

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...

[2] https://stallman.org/stallman-computing.html

Ummm, so first you state that "PC is too damn crufty and complicated" and then suggest that going full-Stallman would improve that, when RMS is using X60, which is essentially a regular x86 laptop? Granted, it doesn't have the IME crap and runs libreboot, but otherwise it's still regular x86 machine. Also, I doubt RMS is after freedom in the first place - it likely improves security (no binary blobs etc.), but it certainly doesn't fix the issue.

FWIW I don't think you've answered the "What to use instead, then?" question. I agree there are platforms that are much tighter on security compared to x86 (say, iphones seem to fare quite well), but I don't see how I could use that for my "regular" work. For that, I think Qubes is "reasonably secure" but hopefully it'll get better.

Of course, if your threat model includes guys from NSA/FBI/Mosad, then perhaps it's not enough. But then again, iphone may not be enough either.

> FWIW I don't think you've answered the "What to use instead, then?" question.

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.

[0] https://en.wikipedia.org/wiki/Burroughs_large_systems

I'm very excited that Microsoft is moving in the same direction. The feature Windows Defender Application Guard (WDAG) runs Windows applications, right now only the Edge browser, in a virtualization isolated container[1]. Under the hood it's using what Microsoft calls "Hyper-V Containers", which are lightweight virtual machines that share some host resources such as a read-only filesystem. The closest open source analogues to that are Intel(R) Clear Containers[2] and Qubes.

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...


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.

HP has virt isolation for Chromium & IE, via Xen derivative from Bromium: http://www8.hp.com/us/en/hp-news/press-release.html?id=24054...

I'm only half-excited about this because I worry Microsoft has no intention to do either one of these:

1) Support anything other than Edge/its own apps

2) Allow the feature to be accessed by users of all Windows editions

I understand for now it's still experimental and whatnot, but I'm not getting my hopes up.

I think that "The closest you can get to Qubes on Windows" is what https://www.hysolate.com/ are building

>Virtual Air Gap

lol. the whole point of an airgap is that you can very easily -at a glace- verify that the system is secure because there's no inputs/outputs to/from it (air gapped). trying to implement it using a hypervisor turns it into a buzzword.

It might no longer be as simple as at a glance in a world with ubiquitous wireless. You'd have to take special care to disable or disconnect all wireless chips in your system. And that might be hard for laptops and impossible in lower form factors.

Even without radios, there are lots of different ways to get data in and out of an airgapped system. Examples include everything from sound (especially ultrasonic beacons etc. as these are used for cellphone marketing today) to more esoteric stuff like flashing the LEDs in a specific pattern or even changing the cpu temperature to specific levels.

Or how about the AM radio transmitter that is built into all x86 hardware - https://github.com/fulldecent/system-bus-radio

Facts are lost in the world of marketing, all that matters is ctr and conversion. I wonder if we can do something about this?

Make people care more about reason and logic than emotion when making product purchasing decisions? I don't think we'll get very far with that goal.

> right now only the Edge browser

Did you know if you force remove Edge from Windows 10 it will forever after ignore the "always use this" checkbox and prompt you to choose your default browser every time the browser is called from a link in an application?

What I'd really love to see is a marriage between NixOS and Qubes, allowing for full-system declarative configuration, including the various systems which will be running under Qubes.

NixOS has containers that show how this could work, but they're only via systemd-nspawn, so not as jailed as Qube's domUs.

Me, I'd like to see such a marriage between NixOS and GenodeOS (which provides capabilities management and has the advantage of using a microkernel as base, so much smaller attack surface, aka TSB, than Xen + Linux)


Genode now has its own package management system with the 17.05 and 17.08 releases, informed/inspired by the work from Genode/Nix (linked in the other comment).

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.

Interesting, thanks for the info! Though from the article about the system (https://genode.org/documentation/developer-resources/package...), it's not clear to me how to:

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?

An abandoned attempt: https://github.com/ehmry/genode-nix

IIUC, it didn't build the whole OS, it was more of a port of Nix, not whole NixOS, to Genode. But I may be wrong. As such, it could be seen as a step towards the goal. But I believe a different approach might be also possible: by starting from NixOS, and adding support for L4Linux (thus seL4 - bottom layer), then Genode On Linux (top layer), then somehow connecting the two.

What a coincidence. I've actually been trying to sketch out how to do this in the past few days.

I've also been looking at how projects like Hypercontainer and Clear Containers achieve minimal VM overhead to expand the model to a per-application-instance VM.

Another interesting enabling technology is VirtFS, which can be used for filesystem-level storage virtualization to gain the many benefits of COW and shared caching.

The principal question then is how to allow interaction between different application instances without the user having to manually ferry files between them, as it currently happens with AppVMs on Qubes.

Could they just copy how iOS does interaction? Different menus like the share menu for example or the password manager menu? I can’t really think of what interaction I need besides maybe ide or terminal stuff.. are both of those systems restrained by qubes? Every bash command is in its own vm? Even so the terminal should still be able to redirect outputs between programs so that can’t really be a problem can it?

Is chromes process per tab model restricted? Forking and piping in general perhaps?

That definitely is the first thing that comes to mind, but applications need to be built under that model.

Currently all applications assume they get access to everything by default, so even if one was to be able to implement a confirmation dialog, the user would be victim to a battery of requests.

This is not to mention that isolation excludes discoverability, so users would have to manually make files visible to other applications beforehand.

Hmm so I suppose the only problem is that developers are t aware they’re targeting qubes/ aren’t designing around qubes yet? Seems like a non issue really, since if qubes gets any traction it will literally solve itself.. although if it doesn’t get traction I suppose that’s slightly annoying tk deal with

Being incompatible with most available software is not a 'non issue'.

The problem won't solve itself by adoption if it never gets to that point, that's almost a perfect catch-22.

I am using both Qubes and Nix(OS) and would love to combine the two somehow. Nix store doesn't mix well with the template system used by Qubes.

Version 4.0 should be out soon (at RC2 now):


Some exciting changes are coming:



EDIT: Downvotes for providing relevant sources, really?

> "EDIT: Downvotes for providing relevant sources, really?"

Sometimes the downvotes on HN make no sense. Looking through your comment history there are a number of recent comments that were unfairly downvoted. Just a guess, but I wouldn't be surprised if it was the same people doing it.

It would be interesting if HN detected such behaviour... Then it could ignore some downvotes. I know it doesn't sound like much, but undeserved downvotes hurt...

i wonder if it is because the username...

> EDIT: Downvotes for providing relevant sources, really?

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.

[0]: https://news.ycombinator.com/newsguidelines.html

I've been running Qubes 3.2 for about 10 months on a intel skull canyon nuc. I love it.

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.

[1] https://www.qubes-os.org/doc/copy-paste/

Their weakest point is the hypervisor, Xen, which while a better choice than Linux/KVM, is still extremely bloated and has a poor security history.

Thankfully, better designs such as seL4's VMM do exist, although it might need a little more work [1] until usable for the purpose.

[1] https://sel4.systems/Info/Roadmap/

Xen's hypervisor's size is very small. Qubes is about security and trustability of the whole system. In operating systems for measuring the trustability of the system, one very important measure is the lines of the code. Xen has a smaller footprint in the hypervisor part. Additionally, Xen has a robust model isolation for the drivers. That's why they went for Xen not KVM. But boy I wish to see more seL4. It was sad to see Gnu Hurd/seL4 didn't make it.

Qubes mailing list thread about hypervisor choices:


> 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.

One of the trends I told Joanna about (i.e secure L4 kernels) led to folks developing exactly that. It was called KVM-L4. Here you go.


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.

The problem with Xen is that no major industry player is backing it, especially with Amazon going KVM now.

(disclaimer: working at Google on virtualization security)

Any chance Google will sponsor secure processor architecture standards?

I mean, the US government no doubt had influence on the Trusted Computing Group (too bad the EFF totally shunned it), and through the magic of product binning and chip fab costs, we all have trusted platform modules.

ASLR currently seems wimpy.

I'm certain you are in a position to accomplish a great deal, no matter where you are in the hierarchy. Maybe the future is x86 hardware emulation for user mode processes.

The US and UK governments especially have been sponsoring great architectures for security that are described in enough detail for hardware engineers to implement or straight-up open source. CHERI at Cambridge is one of the latter which already runs FreeBSD. All Google has to do is pay a good team/company to build one that's reusable for their various products and services. Then, they can start targeting those to it at software level for better efficiency.

The project would cost money that Google has. There's not much new to invent, though. They just have to apply what's there. The performance penalties and ASIC costs are even much lower than they were in the past. Google refuses to do these things because either (a) they don't know about them or (b) more likely their management doesn't want to commit that much money to secure hardware. Typical of the big companies with the smartcard market the only exception far as stuff non-enterprises could afford.

For a quick example, they did retool software to support OpenPOWER architecture but could've also funded Raptor Workstation in a desktop or esp server form themselves. It would've been to their budget like pennies are to ours. Not even that. At least they did the Chromebooks, though, which are good for a lot of non-technical folks.

It's Intel pushing that stuff forward, with SGX.

Then from recent Defcon and Black Hat talks, they are an absymal failure. ( https://www.youtube.com/watch?v=lR0nh-TdpVg Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation ) (I don't understand it beyond what everyone says it can achieve)

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.

>SGX is designed to shield software against SMM exploits.

Perhaps if we add one more thing, x86 will finally be secure. You are right, Intel should be left to their own devices.

I'm not arguing that x86 will ever really be secure. However you handwaved a hypothetical "secure processor architecture". Realistically the way you do that is by making a very simple CPU, however, that would then be too slow to be usable for many applications. As a consequence nobody is doing so.

SGX is at least a middle ground - it integrates the memory access checks very deep into the memory access circuitry, sufficiently deep to block all other privilege levels on the CPU. Whilst there may well be implementation flaws in SGX itself so far most attacks have been mounted via side channels, not directly exploiting CPU bugs.

In this sense my original statement was correct. Intel is pushing secure CPUs forward more than any other vendor.

I think a secure processor is very complex, not very simple. The smartest person's working memory cannot operate on more than a few hundred lines of code. A high performance processor that induces a fault when a programming error occurs is certainly very complex.

It is the wrong sense. Intel is playing catchup more than any other vendor and are selling a product that is nothing more than a bunch of cobbled together features, my opinion in the view of the statement that AMD is glued together.

They're actually pretty simple if you're mostly trying to defeat software/firmware attacks. You just add some part to run in parallel with the processor, which can be arbitrarily simple or complex, that checks certain things about the data such as length or data type. The first one was implemented in 1961 hardware with it being secure from code injection until the invention of ROP. That's a long time. I'll add a modern take on that which led to a flexible mechanism that can do a dozen or maybe more policies.



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.


And one open-source one on MIPS for capability-based security that runs FreeBSD:


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.

The theory is simple. I'm somewhat inclined to think it is not so easily applicable.

It is easy to make a secure coprocessor, since the formal logic proofs aren't for such a long set of code.

The fact that rootkits are even possible, that without malware that doesn't involve an elaborate rewrite of the kernel, shows how terrible everything is.

If I didn't know any better, I'd say that Intel is hiring the designers who thought Internet Explorer should be in the kernel.

Ain’t no problem that couldn’t be solved by adding another layer of indirection, eh?

Maybe in web or application software. In hardware, it all runs in parallel. The mechanism of something like SAFE becomes another component receiving input in the CPU pipeline. A conditional of sorts is added so the final write back to whatever memory doesn't happen unless the safety/security checks passed. The failure mode might also do an interrupt for OS so it could log the where and why of the failure. As in, application flaws could be patched quickly.

Seems like you replied to the wrong comment, the intended parent might not see your reply because of this.. probably should repost it in the right place

Hmm. I thought comment chains were limited in length.

Not that I know of.. although the reply button sometimes doesn’t show up.. you just have to click Into a comment if it’s missing for you

SGX is designed to shield software against SMM exploits.

I was under the (possibly outdated) impression that Amazon wasn't really backing Xen much anyway, so AWS changing hypervisors might not mean much to Xen anyway.

I haven't used Xen for a while, but seemed to recall that Amazon forked it way back in the 3.x days and had been doing their own incompatible thing with it since then.

Corrections welcome of course :)

What about Cisco?

Where does Cisco use Xen?

It has common products with Citrix for Citrix XenServer, https://blogs.cisco.com/datacenter/citrix-synergy-round-up-c...


I don't know, doing business like every other major IT company?

>Xen's hypervisor's size is very small.

150kLoC is quite a bit for an hypervisor.

way smaller compared to KVM/Linux's but compared to seL4's 10k LOC it is huge which is why seL4 is a good candidate as industry standard size for trustable hypervisor layer [1] but I am not sure how and what happened to L4Linux project other than being just an academic project!


The Genode team proposed some integration with Qubes a while ago, but not sure if the discussion went anywhere from that:


No, I'd say that the weakest point is the IPC marshalling necessary to connect all of the containers together into a cohesive system. That's what I'd attack first.

A good place to look, but do note that that's the code written by the Qubes OS people - presumably, it's written with security in mind. Of course, Xen has had more eyeballs, so...

Chrome's IPC was written with security in mind too, but most of the sandbox escape exploits have been around IPC marshalling.

Unlike the nitty gritty of how the sandbox works, the IPC changes often with new releases. And quite frankly it isn't as fun, cool, or interesting as VMMs or other sandboxing techniques, so a lot of the time it isn't given the close eye that it should.

Is it possible to run secure code on any Intel microprocessor which supports the x86 instruction set?

I do not think so.

Pre-2006 systems, maybe. I have a PIII based laptop that I'm reasonably sure doesn't contain any malicious microcode or BIOS shenanigans. It certainly doesn't have IME or equivalent. However, that was the CPU that started Intel's serial number controversy, and while I do have a BIOS setting to turn it off, is it really off?

It's a pretty deep rabbit hole if you really want to go down it. You can make a case for not trusting any CPU that you didn't design and fab yourself, and even then you have to watch out for your own mistakes and bugs that can be used against you.

Could you clarify "Better choice"?

I've been using KVM/Xen/VMware for some time and always enjoyed it. And since Amazon and Google especially are going all in on KVM I'm surprised to hear the Xen is a better choice.

>Could you clarify "Better choice"?

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...

It should be noted that KVM supports many different archs, and it lives inside the mainline Linux kernel while VMware's kernel modules are out-of-tree. I think this fact is an important difference (also that qemu-system-* are open-source, while vmware is not).

Why is a type 1 hypervisor instantly considered more secure though? I'd assume using Linux, instead of rolling your own code to interface with hardware, would make you more secure?

In the Linux vs Xen example, the TCB is much bigger with Linux. The idea is to keep the TCB as small as possible, with an emphasis on restricting the code size that's actually running privileged.

sel4's virtualization support make it a type 2 hypervisor. Akaros too, which IMO has the right model for virtualization with it's 'VM threads' concept. All 'type 2' really means is that the kernel directly supports running threads in ring 3 in addition to ring 0.

I guess it's your use of 'proper' that bugged me.

Amazon is going KVM?

Ah - https://www.theregister.co.uk/2017/11/09/aws_deletes_new_hyp...

Sorry for not googling before asking...

You also have access to BHyve on FreeBSD for a good hypervisor.

Just like KVM, bhyve includes a whole unix kernel in the TCB. Sure it's a better one :) but still.

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 :(

I ran Qubes on a laptop for a while. 1) It's a huge battery hog. 2) It's a real pain to run a non rolling release distro (i.e. Arch). Some dependency is going to try and upgrade itself that can't and it will brick your whole distro. Even being locked to a specific release proved a bit of a pain. It just adds a lot of complexity to your day to day operations (i.e. opening a program is a tiny bit more complicated) that turned out to be a huge drain for me.

Running an HVM with a separate kernel should alleviate those problems. Qubes is phasing out PV support anyway.

I encounter an equal amount of complexity in my KVM workstation as I did in my Qubes workstation, and more problems.

For example, lack of a secure copy/paste mechanism, meaning I must type passwords by hand to avoid every VM being exposed to the clipboard.

Note that while Qubes OS uses full-disk encryption, it runs on Xen, which does not support hibernate.

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]

[1] https://github.com/QubesOS/qubes-issues/issues/2414

Silly. If you did fully shutdown, you're now much more vulnerable to an evil maid attack, which that same advisory could employ. And now you haven't been tipped off there was an attack to begin with.

Hmm, I commend your point, however I think there is room for debate on both sides.

To defend hibernation/shutdown: if I lose my laptop or it is stolen, and I realize I will never see it again, then at least I will have peace of mind that no one can ever recover the data, assuming I had a strong password.

An evil maid attack assumes I will have the laptop in my possession again. This is a different problem, and requires different measures to defend against. I'm interested in hearing why you think leaving a laptop in sleep mode protects it from an evil maid attack.

If a highly skilled thief wants to break into my house they could jimmy the latch on the window and let themselves in.

I don't have any bars on my windows to prevent that.

You need to draw the line somewhere.

Yeah, I'd say it depend on if you're a normal user or Edward Snowden. Do you have really sensitive data that could cost you your life? Then you have to worry about these edge cases. Are you a normal guy who wants to browse for porn safely, then this is already pretty good privacy.

Do you consider your credit card number sensitive? Your username and passwords to all of your, bank accounts, social media accounts, and email accounts? Your personal photos? Your personal notes with personal information about your family? Your track record of your interests and hobbies?

I do. And, if I have a choice, I'd rather not have to wonder if this data is in the hands of a stranger after my laptop is stolen.

It has to be stolen a) while it's on, and b) by someone who immediately knows what to do.

I'm quite sure if you look at your average thief and multiply these to chances together that's less than one in a million chance to happen. Assuming you're not some high profile person where the right person is out to get you and knows which OS you use, and knows how to steal from you.

I agree that bars on my windows are a lot to ask for, and lack elegance and convenience.

My Linux OS can hibernate, and I've not found it to be noticeably inelegant or inconvenient. I suppose others' opinions may differ.

Whatever happened to the Qubes-Purism marriage? They were on track to start Qubes-certifying Librems, and selling Librems with Qubes pre-installed ... then they cancelled the plans, and I never heard why?

FWIW, it seems that when you buy a Purism laptop there is an option to include a Qubes live usb in the deal. I just came across it while skimming through their website[1], not sure about anything else.

[1] https://puri.sm/shop/librem-13/ - see the Operating System choice

Thanks. I know about that. They used to sell Librems that had Qubes pre-installed, and they were on-track to get Librems to be the first officially certified hardware for Qubes. Then they canceled the whole thing, and now, as some kind of consolation/compromise, they offer Qubes-on-a-stick purchase option.

Can it also protect against key-loggers, i.e. if i'm running an app in a qube, can an app in a different qube read my keystrokes?

Yes, it will protect against keyloggers. Unless you install the keylogger on both qubes.

You can have a separate "qube" that is not connected to the network where you would store your passwords, etc.

Nope, not unless your keylogger is installed in the dom0 qube, or is a hardware one.

10 years ago, I helped design a similar system. It was a capabilities based OS on a formally modeled microkernel.

I'm still not sure than there's a market for this stuff. It must be free, and it's hard to build a business model around that.

When Joanna said nothing like Qubes existed, I told her INTEGRITY PC was doing it around 2005 using separatiom kernel approach with stronger security. You must have worked on that one given 10 years remark. Im curious about your experiences with that. Email me if you want details confidential. Rarely meet folks doing the kinds of architectures I research and push for further adoption.

I wish there was a way I could try it. The hardware requirements ...


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?

I'm running Qubes 3.2 on my laptop right now (Dell Latitude E5470) and it also fulfills all the requirements to run 4.0.

The certification requirements are higher, but that's basically if people want to stick the Qubes-certified label on their devices, signaling to customers that it measures up to the highest standards of security.

They're not necessary to run Qubes, they're just ideal.

I run Qubes OS on my Thinkpad T430s for 1.5 years now. Everything worked out of the box.

A least around a year ago, Purism shipped computers with Qubes and claimed to be the "only approved hardware vendor".

EDIT: See https://news.ycombinator.com/item?id=15735911

How about Subgraph OS? It has grsecurity patch, tor network, container isolate, firewall. It's another good choice also


openbsd vs qubes os, which one will you prefer?

As an OpenBSD fan: consider Qubes instead if you want a "desktop" experience. OpenBSD works fine, but the open-source desktop is quite vulnerable (consider how many things need to go wrong for https://scarybeastsecurity.blogspot.nl/2016/12/redux-comprom...), and a lot of OpenBSD's hardening is in the (simpler) base system, not in GNOME / KDE / Firefox / Chrome / ...

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.

Wow, your recommendation for desktop security is either not running a full-blown desktop or running Windows? As in, Windows beats the popular Linux distros in desktop security?

QubesOS -> Secure Desktop

OpenBSD -> Secure & minimal Server

OpenBSD doesn't have the isolation and hardening on the desktop apps, as Qubes has.

I run both -- but which I'm using at a particular time depends on the particular use case.

For this article's target audience, Qubes OS is the better choice.

Are openbsd and qubes really comparable?

To a certain degree. If you're unfamiliar with OpenBSD, security is basically its #1 priority and it's often recommended when you want better security on your server

Damn, I was really hoping this was an (early) announcement for 4.0 (or at least an -rc3).

Same here. I'm waiting for 4.0.

QubesOS won't protect you from Intel ME though.

Purism laptops do.

I wouldn't trust that company at all, they lied and misrepresented themselves for nearly three years before finally claiming to make good on what they sold their customers. Beyond that, they didn't fix it themselves as they say, they relied on the work of other projects then claimed they did it alone.

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...

IIRC they didn't really lie, everything was always worded like "will be free in the future".

Also the post you linked to directly gives credit to me_cleaner and Positive Technologies.

The reason the researchers required physical access:

> Although some systems do allow the full contents of the BIOS flash chip to be reprogrammed using software tools only (so called 'internal flashing'), on most PCs this facility is either completely unavailable, or can only write to the unprotected areas of the flash filesystem (excluding the ME area), or will only write vendor-signed images. Accordingly, we will describe the approach of using 'external' flashing in this guide, as that is the most reliable.

Purism being, uhhhh, the vendor, allowed full write access.

> "Purism being, uhhhh, the vendor, allowed full write access."

If that was the case they could have shipped IME-free machines from the start. They are selling whitebox machines for an exorbitant markup with their own spin on a Linux distro.

That's incorrect. Allowing internal flashing just requires setting certain parameters in the flash to being read-write, and doesn't require any of the flash modification necessary to disable IME.

Disabling IME can have other impacts, and Purism even has a blog post explaining what the issues were and how they resolved them -- once they figured out what IME modules were needed for their laptop to work properly they could disable IME with a software update.

I don't know if that's how they did it, but you're misunderstanding the difference between disabling IME and enabling internal flashing.

Killing ME my new now QubesOS running T470p took under twenty minutes (though requires a flash programmer).

God knows, there are several other embedded CPUs in the thing that have who knows what kinds of vulnerabilities... but better is better.

Or you can buy a Thinkpad T400 :)

Fun fact. The developer does not believe in using a password on her private keys.

If you have your keys on an air gapped computer with an encrypted hard-disk, I don't see the need to use an additional password on the private keys.

If you mean air-gapped literally, that seems unuseful.

Wouldn't you want the keys on the computer that's going to use them? And then, wouldn't you want to make it hard to copy the unencrypted private keys?

(I'm assuming we're talking about SSH keys.)

OTOH, it could be neat to run an ssh agent in a key-holding qube and forward that to whatever qubes need to use your SSH keys, using `ssh-add -c` so that key use must be confirmed in the key-holding qube.

Sound exactly like split-GPG


One possible benefit is giving you enough time to discover the breach and rotate keys before the keys are compromised

If they somehow break the encryption on your hard disk it’s just more security.. isn’t that what security’s all about? Getting the most safety you can get? What need is there to have an encrypted hard drive if your computer is air gapped? It’s just a better safer idea, no?

Security is not about getting the most safety you can get. Otherwise why stop there? You could store the password protected private key itself as an encrypted file on the encrypted disk, and add one more layer, or double-encrypt it and add yet another layer etc.

The assumption is that the encryption can only be broken via an evil-maid attack.

If you are victim of such an attack, the encryption of the file is broken as well.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact