Andrew:
> pleom...@gmail.com:
>> 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
points:

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!

Andrew

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/70244db2-44a2-e5f7-c09c-1c320307fdac%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to