Hacker News Reader

Comment by DyslexicAtheist | Hacker News Reader

"You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."

-- Theo de Raadt (on the statement "Virtualization seems to have a lot of security benefits")

View on HN

Theo is wrong with respect to Xen. You might enjoy section 3.1 and 3.2 from the Qubes Architecture document: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a...

The attack surface of Xen is much smaller than a traditional kernel like linux. I'm guessing the same can be said for OpenBSD after looking at the number of system calls.

Xen has had it's fair share of vulnerabilities, and the author of the document you linked also had this to say: http://lists.xen.org/archives/html/xen-devel/2015-11/msg0060... (follow the links)

Absolutely. It should also be mentioned that many of the Xen vulnerabilities are actually due to qemu and that emulation can mostly be avoided by using PV/PVH.

The Xen attack surface is then reduced to about 20 hypercalls (even less for ARM). http://xenbits.xen.org/docs/unstable/hypercall/index.html

The number of hypercalls isn't a good indicator of the attack surface area.

As examples:

There is a full x86 instruction decoder which is technically not part of the hypercall interface. x86 instruction encoding is surprisingly complicated. There was a vulnerability in that code: http://xenbits.xen.org/xsa/advisory-123.html

Handling x86 page tables and all of the various feature bits is also surprisingly complicated. This is part of the hypercall interface, but there was also a vulnerability in that code: http://xenbits.xen.org/xsa/advisory-148.html

You might enjoy the fact that my early critiques to Qubes told Joanna Xen was a security problem she should've avoided in favor of separation kernels w/ user-mode Linux virtualization, user-mode drivers, and a trusted GUI subsystem. She vigorously argued against that on the mailing list. Years later, they now have some kind of trusted GUI schemes and she's griping at Xen for being insecure. I don't know if she reduced privilege of drivers or has since learned why that's a good idea. The 180 was hilarious.

I'm sure their product will have plenty more vulnerabilities as she lacked foundational knowledge in building secure systems. Meanwhile, with little labor, GenodeOS was incorporating many well-designed components from the start such as L4 work, Muen, seL4, Nova microhypervisor, Nitpicker GUI, etc. They're still alpha quality due to clean-slate work needed in that approach but moving on steadily. Check them out.

Note: For appliances and embedded, JX Operating System is also worth Googling. Remember that JVM can be replaced with Ada, Go, etc runtime or Rust.

Do you have a link for that discussion? I've been using Qubes for awhile now and the GUI has always been in DOM0 with no networking.

She censored my critiques from that point on. All I have is a cached copy of what I sent in response to her dismissing my comments on the mailing list. Fortunately, I often quote relevant points before countering them. You can easily see what each of us pushed. Her Mac OS X claim makes me laugh to this day.

http://pastebin.com/b8Tz5jW1

"and the GUI has always been in DOM0 with no networking."

I'm clearly not a Qubes user. I'm basing my statement on what articles or comments here described as relatively recent work isolating the GUI stack further from attack. If that didn't happen, I retract it. The Xen, Dom0, and driver risks she ignored and countered directly so I was sure they'd be a problem.

EDIT to add: Btw, she later did a one-side rebuttal countering various things here on her blog while censoring my rebuttal of course. One real problem she identified was my use of "military-grade:" commonly a buzzword indicating snake oil. I read lots of defense stuff back then but forgot to translate. I meant Type 1 certified by NSA for high-assurance use in military. It's a rigorous process identifying and often preventing... many issues people found in proprietary and FOSS products designed without high assurance practices. ;) So, I started saying NSA Type 1 certified from that point on to avoid confusion.

Thanks for taking the time to post that. Many of those statements are surprising given how well designed Qubes looks on the surface. I wish more people nitpicked projects like this. Please consider trying Qubes 3.1 out and posting a review. I'd love to read it.

I'm down to a few pieces of hardware and wary of doing anything heavyweight with them. I do want to try it out esp it's usability and such. What's resource usage like for it on single or dual core hardware?

The minimum requirements are pretty low: https://www.qubes-os.org/doc/system-requirements/

I've only used it on mid-high end systems though. You should easily be able to launch a few small VMs (each AppVM is tunable) on a dual core machine with 4 GB of RAM though.

Xen is worse than Linux in terms of quality, and therefore security. That Linux is much bigger doesn't make Xen any better.

What de Raadt means to say is, generally speaking, you can't build security on top of bad code. No amount of patching, sandboxing, or whatever will help. Security comes from quality and Xen (like Linux) is very lacking in quality.

TCB matters. If you have data to back that quality statement up, I'd very much like to see it.

Paul Karger helped invent information security, pentests, secure coding, high assurance, and so on. He and the other old guard paved the way for the types of systems that survived rigorous pentesting. One of his works was a virtualization product for OpenVMS done because securing full OS's was too hard to achieve.

http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A...

If we're talking experience and lineage, then we should ignore Theo on this issue immediately as he's never constructed a provably secure system. They don't even address covert channels much less be able to tell me every successful and failed execution trace of their OS w/ argument they obey security policy. Of course, if you look at Karger's design and assurance sections, you'll know the minimum required to get close to secure, predictable operation disqualifies Xen, KVM, VMware, etc from the picture as well.

Only the separation kernels (eg INTEGRITY-178B or LynxSecure), Nizza architecture, GenodeOS, JX OS, CHERIBSD, etc are consistently applying the lessons of the high-assurance community. One of them is that microkernels and core VMM's are the easiest to secure with other stuff running on top mediated by a security policy. Many such systems survived NSA and private pentesting. Monoliths and UNIXen rarely do.

I'd say that it's a trade-off whether you think the enhanced isolation provided by containerization/virtualization is more of a security benefit than the risks posed by the increased attack surface of another layer in the stack...

I think that statement is factually wrong, but before I get into that, I don't see the relevance of a claim about x86 virtualization (which is what de Raadt's post was about) to the article here, which involves no x86 virtualization at all. There's some discussion of Linux container isolation, but the analysis of whether you can get that to be more secure than uncontained Linux is basically completely different to an analysis of hardware virtualization (leaving aside that it is generous to call a data-less opinion from a decade ago an "analysis"). Am I missing a reason why this quote is relevant?

Here's the context: https://marc.info/?l=openbsd-misc&m=119318909016582

I don't think the actual technology he was talking about is relevant.

The message is that people writing the linux kernel make a lot of mistakes, and it result in security holes. Those same people (or the same kind of people) also write X (Docker, x86 virtualization, whatevs...), so mistakes and security holes are to be expected.

I do not necessarily agree with the message, but this is how I understand it.

I understand that message, but it's so little of a message that it doesn't seem useful. Why should we believe that it's equally easy to make mistakes and security holes when writing kernels, OS virtualization, and hardware virtualization? The security models of these things are very different (for instance, a kernel has multiple user accounts, hardware virtualization has just "admin" and "VM"), the underlying designs are very different in complexity, the requirements for legacy compatibility are different, etc. etc. etc.

Reply on news.ycombinator.com