>> If there is no user acces control like a real root real user then its no 
>> sense to use it.
> I think you've missed something pretty fundamental.
> Throw out everything you know about the Linux kernel and how it enforces
> security (including MAC).  Qubes takes the position that the Linux
> kernel code base is simply too large and complex to meaningfully trust,
> and that any security policies must be enforced by a smaller, more
> trustable hypervisor.
> The security problem is then less about user accounts, process
> separation, etc. and more about ensuring guest VMs only modify their own
> state, and interact with other VMs only through simple, easier-to-audit
> and easier-to-securely-implement channels.
> IMO all the Qubes magic is about these over-the-top channels.  You can
> use bare Xen (or ESXi, or HyperV or whatever) to get similar VM
> isolation, but it will be cumbersome to orchestrate typical user actions
> (inter-VM file copying, PDF conversion, networking/firewalling,
> trustable DWM, ...).  Qubes makes it easy.
> Andrew
> PS: Let me give an example.  Suppose your typical Linux desktop has a
> 'user1' account and a 'tor' account.  Suppose the latter is used for
> running a Tor relay.  Normally you would expect the Linux kernel to
> enforce access control, to ensure any code running with the 'tor' uid
> will not be able to access 'user1''s files.  In Qubes, you just install
> Tor into a separate VM from the VM you use for the 'user1' persona.
> Thus the barrier for Tor to access 'user1''s data is the hypervisor, not
> the Linux kernel.

Sorry for adding to the spam, but I feel obliged to add two important

1) It's not just the kernel.  Practical user security depends on a lot
of userland system components, too.  That's why it really is appropriate
for Qubes to abstract security domains as independent VMs.

2) While I wrote 'similar VM isolation', I still believe Qubes is the
most secure practical virtualization platform.  For example, the VENOM
(CVE-2015-3456) vulnerability affected nearly every other Xen
vendor--but not Qubes.  To quote Marek:

"[The solution] is already there - there is no other option in Qubes.
We've never considered running such a bloatware as qemu directly in dom0
;) "

This kind of security-first posture is what has made Qubes famous.
Trust it or not, but I hope the architecture now makes sense!


You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to