Understanding Qubes OS VM Security Decisions: Why easy root access in VMs? Why is ~/.bashrc and similar not protected?

General Discussion
1

Hello!

i want to understand the security Properties of qubes OS on a deeper Level. Notice, for all my arguments/questions a simple “yes, but the increases security would be too low compared to the cost of implementing it” would be sufficient. i understand many ideas are a lot of work.

1) Easy Root access in VMs
to quote Passwordless root access in qubes | Qubes OS

# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- as of 2016, there have been only three publicly disclosed
# exploitable bugs in the Xen hypervisor from a VM -- then it would be
# highly unlikely if that person couldn't also found a user-to-root
# escalation in VM (which as we know from history of UNIX/Linux
# happens all the time).

That is true, but i think it would be harder if the VM “personal” (i.e. not the template that provisions the VM!) would have not way of accessing root. So if there would be no sudo/su binaries(it is simply not needed for the “personal” VM), and no other way of authenticating to root (for instance polkit), it surely would be more difficult?

I imagine, all user-to-root escalations are easy because the usual linux installations require users to sometimes escalate to root. But here, if no one can escalate to root, then also the attacker cant?

# At the same time allowing for easy user-to-root escalation in a VM
# is simply convenient for users, especially for update installation.

I understand that for the VM that configures the template. But the VM that uses the template, there is no use for that.

2) attacker is allowed to execute anything they want

even more: when i have a VM that is solely for running firefox, denying the execution of everything else would make an attack surely much more difficult compared to “attacker has full control to run everything they want in the VM”

When i have some important personal files on this VM, for which i dont want to create a separate VM to keep the management complexity low, an attacker can very easily steal these files.

3) attacker has read write access to $HOME
if firefox couldn’t even read anything besides $HOME/Downloads, they also wouldnt be able to steal anything from my personal files.

And for instance, they can easily gain persistent access to this VM by deploying their attacker executable to somewhere in $HOME and executing it in ~/.bash_profile or sth.

But when they couldn’t even modify these files in the VM, they also couldn’t persist their access into ~/.bash_profile.

That way they surely could find a way to always change the DNS server of this VM everything firefox or sth starts. (either the firefox config itself, or via files in /etc)

4) documents describing the security properties of qubes OS

I know of course the Documentation on the website where also some of this is described. I also know the “Qubes OS Architecture” Version 0.3 from January 2010 by Joanna Rutkowska and Rafal Wojtczuk. (but i haven’t read it yet)

Are there any other documents describing the security on a deeper level?

1 Like
2

If you really want to lock things down in qubes then you certainly can. You could for instance get rid of passwordless root and then resort to using “qvm-run -u root appVm docommand” from dom0 to do all your maintenance, which you would think makes it near impossible for your machine to get hacked, but then it would also be hard to get anything done. Try starting with fedora-4x-minimal without su and see how easy it is to use.

But then the hackers can just come in through your browser. Once they are in your VM, root or not, your already toast, so get out your backups and restore. To a nation state actor getting root is more trivial than you think, so lack of su might just slow them down a little, but the hardware compartmentalization of Xen is a lot less trivial to circumvent. With or without su that vm is about as far as they go, and your already going to have to wipe and restore it. Your biggest problem then is did they exfiltrate something, and if so why was that data even in a Vm that they could get to via the internet?

It’s all about compartmentalization.

Security is always a trade off with convenience for sure. Not everyone’s threat model is the same. In my previous life before retirement nation state actors were a real thing, but now the standard configuration of qubes is ample for what I am doing. I no longer use a retracable hardware token attached to my belt in order to login. Hard to stand up and stretch your legs without logging out and locking the screen.

3

Qubes focuses on the isolation at the virtual machine level for the most part. That is already a gigantic task. But it does in no way restrict users from implementing security in-depth mitigatiins. Even thiugh, comparably they may not give similar assurances, but they increase an attack’s cost.

You have Architecture | Qubes OS and Documentation | Qubes OS