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 email@example.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.