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. -- 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/1af259c8-f9ea-a631-3204-836d435f344f%40riseup.net. For more options, visit https://groups.google.com/d/optout.