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


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.

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