LWN: Comments on "Qubes OS 3.0 released"

Qubes OS 3.0 released

zlynx — Mon, 26 Oct 2015 19:16:52 +0000

I think you missed my point that programmers are rapidly increasing the attack surface of virtual machines. It won't be long until it is just as large as the system call surface.

On the other hand, why use virtual machines when you can get the same effect by reducing the system call surface?

Qubes OS 3.0 released

Rudd-O — Sun, 25 Oct 2015 03:33:52 +0000

You need to read the Qubes OS whitepaper (pinned right there in @rootkovska's Twitter) to understand why your notion of "kernel separation" is illusory. Nothing is "just as complete" when the attack surface is orders of magnitude larger.

Qubes OS 3.0 released

Rudd-O — Thu, 15 Oct 2015 01:40:08 +0000

What Joanna and others have done with Xen (not Linux) has nothing to do with what the Solaris people did. Solaris provided a less-than-type-2 non-hypervisor. Joanna integrated a type 1 hypervisor in a functional way, such that you could use it without much thought except for compartmentalization, which was always your obligation as a security-minded person. Superior.

Qubes OS 3.0 released

Rudd-O — Thu, 15 Oct 2015 00:54:21 +0000

When Qubes OS 3.0 is released (or, now) you sit back in awe at the power of Invisible Things Lab, that hath brought to you the mostest reasonablest securest OS that you have ever seen.

And, hey, seriously, it's god damn secure.

If you're not using it, USE IT. NOW.

And if you need automation to configure your VMs, keep an eye on here: https://github.com/Rudd-O/ansible-qubes , for I have to write the glue that will cause you to drive your Qubes system with Salt, Ansible and many other automation systems. Enjoy!

Qubes OS 3.0 released

robbe — Wed, 14 Oct 2015 13:16:50 +0000

Nope. Sun Fire X4170-M3 (called Sun Fir X3-2 now) is still sold, and has a bog-standard BIOS/UEFI ... no OpenFirmware. See
http://docs.oracle.com/cd/E22368_01/index.html

But I'm sure you can point at documentation of Solaris Trusted Boot on *x86* for concrete hardware?

Qubes OS 3.0 released

Rudd-O — Sun, 11 Oct 2015 19:11:06 +0000

Qubes doesn't emulate hardware. The hardware is directly passed-through to the VMs via PCI.

Qubes OS 3.0 released

nix — Sun, 11 Oct 2015 16:14:47 +0000

Yeah, that too, but I figured I'd come up with enough reasons it was totally useless already. :)

Qubes OS 3.0 released

kloczek — Fri, 09 Oct 2015 13:27:27 +0000

You may ave impression that my knowledge of Solaris is deeper than Linux one.
In reality situation is opposite.
My first Linux been working on pre 1.0 kernels. I've started using Solaris 8 few years after I saw first time Linux.

Qubes OS 3.0 released

sjj — Thu, 08 Oct 2015 18:36:38 +0000

People here have responded to your commentary pretty respectfully so let me open my flame thrower on a low setting.

You obviously know a *lot* about Solaris and are very invested in it. This is great, but I'd like to request you to change the tone of your comments toward being constructive - many here, including me, are interested in understanding different OS approaches to the same problems. I'd like to learn instead of reading passive-aggressive diatribes about how Linux is worse than your preferred OS. I admit I am invested in Linux, it has largely defined my professional life even when I was a full-time Solaris admin (this was when Solaris was strictly proprietary). But I also know that Linux will be supplanted sometime in the future - the largest Linux OS today has a totally different userland already. I just hope the next thing powering the internet is Free software too.

I haven't touched a Solaris box in several years because they are largely being phased out in the companies I've worked at. This is a pretty common experience with sysadmins in my circles. Oracle has made Solaris obsolete in the modern world other than in some niches. This is an observable fact. You can ask yourself whey they forked RHEL in the first place if they already had a superior OS. Yes, Solaris has some great features, but its technological lead over linuxen isn't anything like 15 (10? 5?) years ago.

Back in the day on Usenet I frequented some OS discussion groups and the most amusing people were some Amiga dead-enders. I would honestly appreciate your contributions to this site from your Solaris perspective with less vitriol.

And this thread got totally derailed, which is sad because I would have liked to discuss Qubes. It's a very interesting project.

Qubes OS 3.0 released

dunlapg — Thu, 08 Oct 2015 14:28:03 +0000

Sure, everyone would like 0 security bugs; but that's simply not available. There are trade-offs between performance, functionality, flexibility, and security, and everyone's got to make their own decisions. If you're not doing multi-tenancy, and you don't need super-strong isolation between your servers, then containers are probably the way to go. If you're doing multi-tenancy, or you need strong isolation between your different servers, use virtualization.

Qubes OS 3.0 released

PaXTeam — Thu, 08 Oct 2015 14:18:00 +0000

> There's an order of magnitude difference.

that's a difference in *insecurity* where you have lots of shades of grey, however everyone wants security instead (0 exploitable bugs).

Qubes OS 3.0 released

dunlapg — Thu, 08 Oct 2015 13:38:16 +0000

The insecurity comes from software flaws which are just as possible with hardware virtualization.

Yes, vulnerabilities are mistakes in programming, and these can (and do) happen in either an OS or a hypervisor. However, the amount of vulnerabilities you actually get will depend on the amount of opportinities to make a mistake. The larger and more complicated the interface, the more opportunities there are to make a mistake.

The thing is, the interface provided by the Linux kernel is much larger and much more complicated than any interface exposed any hypervisor (either KVM or Xen). Look at the number of security vulnerabilities which allow you to break out of a process into the kernel (privilege escalation), and compare that with the number of vulnerabilities which allow you to break out of KVM or Xen into the hypervisor. There's an order of magnitude difference.

Check out this presentation for more information and some concrete numbers.

Qubes OS 3.0 released

gasche — Thu, 08 Oct 2015 12:41:43 +0000

> The insecurity comes from software flaws which are just as possible with hardware virtualization.

Of course, but the point is that the Trusted Computing Base is *massively* larger when relying on containers for security than when relying on supervisors. It is much more reasonable to try to secure, audit and eventually prove secure¹ a hypervisor than a monolithic kernel. Linux containers are virtually guaranteed to have security flaws for the years to come, just because the attack surface is so large.

¹: there are several projects working on provably secure hypervisor codebases right now. It would be reasonable to use them with Qubes OS on top.

Qubes OS 3.0 released

ibukanov — Wed, 07 Oct 2015 06:59:39 +0000

> but if you allow *that*, it is utterly trivial to bypass the signing by copying unsigned executable code unchanged from an unsigned binary (not mmap()ed executable, so not verified) into non-file-backed memory and then executing it.

Or one can just mmap a signed executable or library and use https://en.wikipedia.org/wiki/Return-oriented_programming .

Qubes OS 3.0 released

mathstuf — Tue, 06 Oct 2015 19:29:54 +0000

Jails miss user namespaces (and associated filesystem support). If you have root in a jail and a user on the top-level system, writing a suid binary in the jail and running it on the host is trivial escalation.

But for lightweight "don't see other things on the system", they work wonderfully (and ezjail-admin plus momentum is why I still use them rather than anything else; if something nicer comes out for Linux before I do the upgrade to FreeBSD 11 (from 9), I'd probably do the jump). I haven't looked too deeply into rkt yet, but that is the most hopeful based on what I've seen so far.

Qubes OS 3.0 released

nix — Tue, 06 Oct 2015 10:39:26 +0000

I was doing this in 2005, I think, with the digsig kernel module.

I stopped because while it gives you a nice warm secure glow, that's all it gives you: it is more or less useless as a security feature, because there are a *lot* of ways to get executable code running that do not go through execve(), and the number of attack paths that involve writing out a new binary and execve()ing it is not large. You might stop a few percent of attacks, but no more.

Signed ld.so is even more useless as a security feature: Linux never supported that because it slows down ld.so for a useless case (see above) and because, well, we can still statically link, so ld.so is trivially bypassable. What's more, glibc can dlopen() (to a degree) even from a statically linked binary, so all your signed shared libraries don't get their signatures verified either. The only place to do verification on Linux is in the kernel -- but you can't make that work properly because you can open() any file you like and then only later mprotect(PROT_EXEC) part of it -- and if you decree that anything that is PROT_EXECed must come from a signed file, you've broken a lot of existing programs because you can no longer PROT_EXEC non-file-backed memory: but if you allow *that*, it is utterly trivial to bypass the signing by copying unsigned executable code unchanged from an unsigned binary (not mmap()ed executable, so not verified) into non-file-backed memory and then executing it. It doesn't stop such code from then taking over the account and doing whatever it likes, chatting to any other machines on the network, scribbling over the disk, exfiltrating data, you name it.

But then, this feature is not for security -- it's for allowing corporate administrators to prevent their (non-skilled-attacker) user base from installing non-centrally-authorized software. It won't actually improve security, only allow more impressive security theatre and box-ticking annoyance.

By contrast, remote attestation (mentioned by Matthew below) is actually useful for ensuring that remote systems talking to you are not compromised (though I still dislike the idea of it, because it will surely mostly be used to try to enforce odious DRM and anti-user lockdown measures rather than for anything actually beneficial to users).

Qubes OS 3.0 released

nix — Tue, 06 Oct 2015 10:23:51 +0000

Well, it's a tradeoff, isn't it? For some applications you'll want high security and damn the inconvenience, which means minimal interactions with the outside world, no clipboard syncing in case it spies on other apps using the clipboard selections etc -- for others, you'll be happy to take that insecurity in favour of the inconvenience (e.g. when you trust the container contents at least as much as the host, and are using it to isolate away from mistakes, allow separate networking configuration etc -- not all reasons you might want to spin up another machine are because of security!)

Qubes OS 3.0 released

mjg59 — Tue, 06 Oct 2015 08:14:33 +0000

Dells don't have ALOM. How does Solaris perform verified boot on them?

Qubes OS 3.0 released

kloczek — Tue, 06 Oct 2015 07:51:02 +0000

As long as your hardware is on on Oracle HCL list you have chance that answer on your question is positive.
http://www.oracle.com/webfolder/technetwork/hcl/index.html
Most of the Dell hardware is on HCL

Qubes OS 3.0 released

mjg59 — Mon, 05 Oct 2015 21:41:38 +0000

That doesn't answer my question or disprove my assertion. If I install Solaris on a Dell, I'm obviously not going to have an ALOM. And you haven't demonstrated that Oracle's x86 firmware performs any validation of the bootloader. I'm not convinced that you actually understand the topic you're discussing.

Qubes OS 3.0 released

mjg59 — Mon, 05 Oct 2015 21:39:53 +0000

I've been entirely unambiguous about how the Linux support here is limited by the distributions not shipping with signatures. But seriously, if all you support is signing ELF objects, it is obviously impossible to sign scripts. And if you can't sign scripts, then what's the point? You've maybe met some compliance requirement, but you haven't actually improved security.

> I know that Oracle is working now on Linux secure boot to bring support with the same functionalities as it is possible to use on Solaris.

Oracle shipped UEFI Secure Boot support in OEL 7.2, and did so in such a way that you can load arbitrary kernel modules or even kexec an entirely new unsigned kernel. I'm not impressed by their work there.

Qubes OS 3.0 released

kloczek — Mon, 05 Oct 2015 20:31:38 +0000

> Let me guess, the prices were raised and updates were stopped?

Solaris support cost is now exactly the same as Oracle Linux. Support of both is slightly cheaper than RH support.
Where did you found information that support prices were raised?

Qubes OS 3.0 released

ThinkRob — Mon, 05 Oct 2015 18:57:02 +0000

What about FreeBSD jails? IIRC that predates Linux container tech by a long shot (jails debuted in 4.0, back in 2000).

Qubes OS 3.0 released

Cyberax — Mon, 05 Oct 2015 17:34:33 +0000

> So you are comparing at least few years old Solaris and don't know anything about what was done in meantime.
Let me guess, the prices were raised and updates were stopped?

Qubes OS 3.0 released

kloczek — Mon, 05 Oct 2015 17:07:25 +0000

> But it's still possible to verify that all the code you execute is unmodified, which is more than you can do if it's *impossible* to sign scripts.

According to quantum physics it is possible that bucket of water put on open fire may freeze.
Be careful with using "possible" word because meaning of this word can be used on cases which you probably don't know to much and in real life effectively they are treated as *impossible*.

Do you know that any Linux distribution vendor provides support on system which will be running with user space signed binaries?
Please remember that it is quite big number of systems around the word which according to local law cannot be used by some companies if they don't have 3rd party support.
For those companies what Linux provides still it is *impossible* to use.
We are talking here about few hundredths thousands if not few millions physical systems.
On none of those systems which requires secure boot Linux can be used .. full stop.

PS. I know that Oracle is working now on Linux secure boot to bring support with the same functionalities as it is possible to use on Solaris. However according to what I know such support will be not quickly available (it is possible that it would be possible to provide it for non-prod systems within year .. only because on Linux they want to provide more important things like better DTrace support).

Qubes OS 3.0 released

kloczek — Mon, 05 Oct 2015 16:44:30 +0000

ALOM is only firmware on Oracle hardware (x86 an sparc) on kit which still is not EOS.
On x86 ALOM was first time introduced on z20/z40.

Qubes OS 3.0 released

mjg59 — Mon, 05 Oct 2015 16:07:01 +0000

Most x86 hardware has no ALOM. And even on Oracle hardware, how does the firmware verify that the bootloader is unmodified? If that verification doesn't happen there's no point in validating any signatures later, an attacker can just alter the bootloader so it patches out those checks.

Qubes OS 3.0 released

mjg59 — Mon, 05 Oct 2015 16:05:49 +0000

> Just quick question: what happens with those checksumes after signing?

Nothing - these are stored in extended attributes.

> If distribution does not provides signed binaries after each upgrade new unsigned binaries needs to be located and signed.

You can handle that with post-update hooks, but yes, like I said, this is suboptimal. But it's still possible to verify that all the code you execute is unmodified, which is more than you can do if it's *impossible* to sign scripts.

Qubes OS 3.0 released

kloczek — Mon, 05 Oct 2015 15:56:13 +0000

> Yes? That talks about a secure boot mechanism on SPARC. It doesn't talk about supporting UEFI Secure Boot on x86, and it doesn't talk about any kind of measured boot support

Nope .. ALOM is used on x86 as well. This why all binaries on Solaris x86 (not only kernel modules) are already signed.

$ elfsign list /kernel/amd64/genunix
ELF file name: /kernel/amd64/genunix
Elfsign signature format: rsa_sha256
Signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11
Signed on: June 18, 2015 01:02:01 PM BST
ELF file format: ELF64 X86 little endian
Elfsign signature version: 6
OID: 1.2.840.113549.1.1.11
Signature: RSA-2048:
0e891ce175c0407e7b978a80677aef95c60b804783bf86d947a8604003d35f28de112c07fbcaedbc7ff7f9e7420a1e07657951a958c1bf4a9ffb984a497fa72ce2dd0df30f6e43d372e0efc603219a1ee9b5b231c661a74b03de738f243f9c25cfd0dbc70f20c369fe9fd8b1dd6e43e4725fef0bbb1b90b8eaa3ad340b438bd931ed0199e8f6ea7196ea435a7a9539514bad02571771ef101ff537a126d345083250ef60d29692f110fed5234e0ee02d304491624f61979127aa1d78b38eea819fce1039f9dbfd5351d7e52ea9ec177cbdd1ff72334b2e684c666137d3698904b4b8f4bb006e4d2f67572bb6e8951a9ffb43d3c53bef3b9b0c2c602f5a318cf5

Only problem with storing root certificates in UEFI is quite simple: it is to easy to change it.
This is only reason why Solaris does not support UEFI secure boot.

Qubes OS 3.0 released

kloczek — Mon, 05 Oct 2015 15:44:17 +0000

> Linux has all the infrastructure required to permit verification of the interpreter binary, but you currently need to do the signing yourself.

Thank you for confirming that none of the Linux distribution provides signed binary resources.
If you would be asking why something like this needes to be provided just think about two things:
1) Package manager uses own checksumes
Just quick question: what happens with those checksumes after signing?
2) If distribution does not provides signed binaries after each upgrade new unsigned binaries needs to be located and signed.
This makes whole process useless.

Qubes OS 3.0 released

mjg59 — Mon, 05 Oct 2015 12:40:24 +0000

> https://blogs.oracle.com/DanX/entry/verified_boot

Yes? That talks about a secure boot mechanism on SPARC. It doesn't talk about supporting UEFI Secure Boot on x86, and it doesn't talk about any kind of measured boot support.

> Really cannot understand why someone should are about signing scripts if interpreter binary cannot be verified.

Linux has all the infrastructure required to permit verification of the interpreter binary, but you currently need to do the signing yourself. This is clearly suboptimal, but I think it's a better situation than just signing ELF objects and ignoring the fact that they'll then execute anything you give them.

Qubes OS 3.0 released

kloczek — Mon, 05 Oct 2015 11:50:13 +0000

So you are comparing at least few years old Solaris and don't know anything about what was done in meantime.
Thank you for your clarification.

Qubes OS 3.0 released

kloczek — Mon, 05 Oct 2015 11:47:17 +0000

https://blogs.oracle.com/DanX/entry/verified_boot

Really cannot understand why someone should are about signing scripts if interpreter binary cannot be verified.

Qubes OS 3.0 released

mjg59 — Mon, 05 Oct 2015 06:45:34 +0000

Sure, and in some ways Solaris is significantly behind Linux (eg, no support for UEFI Secure Boot on x86, no support for measured boot at all, only supporting signatures on ELF objects). If Solaris matches your requirements, you should definitely use it - but honestly I can't think of many real-world usecases where being able to sign ELF objects but not scripts actually wins you anything.

Qubes OS 3.0 released

edomaur — Mon, 05 Oct 2015 06:33:10 +0000

For me it's quite a long time : my employer replaced it by IBM AIX when Sun got bought by Oracle... Still, most UNIX system we are using are slowly phased out and replaced by RHEL, leaving "only" databases servers on UNIX platforms.

Qubes OS 3.0 released

Cyberax — Sun, 04 Oct 2015 21:06:54 +0000

> In meantime on Solaris has been developed complete solution allowing lock in secure cage stretching from controlling network traffic, kernel space, user space, VFS layer up to secure boot.
Yeah. It's called "being irrelevant". In just a couple of years you'd be able to leave an Oracle Solaris machine wide open and nobody will hack into it.

Qubes OS 3.0 released

kloczek — Sun, 04 Oct 2015 19:36:35 +0000

> I don't think any general purpose distributions do this at the moment.

Thank you for confirmation that after 10 years when some development of some fundaments Linux still is in the same point where it was almost 10 years ago.
In meantime on Solaris has been developed complete solution allowing lock in secure cage stretching from controlling network traffic, kernel space, user space, VFS layer up to secure boot. Everything to enable in few simple moves. Everything under support (try to as RH for support of TPM or other components).
If anyone my be asking why Linux has still no entry in some areas answer lays here.

Qubes OS 3.0 released

mjg59 — Sun, 04 Oct 2015 16:25:44 +0000

> OK you said that I "can". Which one distribution supports this?

I don't think any general purpose distributions do this at the moment.

> Which one Linux distribution provides signed resources and allows over user certificate which is signed by one of the publicly available root certificates to sign my own binaries?

All of them allow you to use your own certificate for signing.

> Which one Linux distribution provides signing tools OOTB/in distro resources?

Basically all of them?

> Which one Linux distribution comes with ld.so with integrated key management?

Like I said, doing this at the executable level is the wrong approach. Sure, you've verified that your python binary is signed. How are you verifying the scripts it runs?

Qubes OS 3.0 released

ms_43 — Sun, 04 Oct 2015 13:15:12 +0000

This is known as para-virtualization and has been pioneered by the Xen project more than a decade ago; KVM also supports para-virtualized IO drivers - the "virtio" interface is even standardized by OASIS nowadays.

http://www.ibm.com/developerworks/library/l-virtio/index....

https://www.oasis-open.org/committees/tc_home.php?wg_abbr...

http://lwn.net/Articles/580186/

Qubes OS 3.0 released

zlynx — Sun, 04 Oct 2015 00:23:28 +0000

The regular ring 3 / ring 0 separation is just as complete as the virtual machine separation. A process cannot do anything without the intervention of the kernel.

The insecurity comes from software flaws which are just as possible with hardware virtualization.

Which is why I cringe whenever I read about new "VM management" software and improved native OS window management and clipboards. All these "features" weaken the isolation between VMs and increase the likelihood of security flaws.