Got any other reason than bind-dirs? Why would the attacker use them in the first place when your home dir works just as well?
Are you referring to secure drops or signing blockchain transactions? I was thinking about sensitive activities that require network connectivity (exchanges, defi, device confirmation, etc.). I suppose the specific example is less important than the user’s perceived threat model and desire to maximize security.
Well this comes back to my lack of understanding of attack methods. My assumption is that the root directory tends to be more protected in general and therefore must be inherently vulnerable to exploits. But I see your point.
@enmus You could configure your VM firewall to only allow access to the IP of your financial service.
I was thinking about sensitive activities that require network connectivity
Qubes OS gives you tools for scenario like this. For example you can configure the firewall rules for that qube in a way that it can only contact a specific IP (range) for your mail server, github, banking website, patient portal etc.
Then of course you would isolate those in dedicated qubes and not have them all happen in the same qube.
If you are an advanced user, you can use qrexec to actually separate the sending/receiving part from the storage part. I haven’t done this yet myself but examples are @unman’s mail setup, split-gpg and others that escape me at the moment.
I guess the idea here is always the same: configure your qubes in a way that should one get compromised you can limit the damage. The key point in the context of this discussion is: once a qube is compromised, it is compromised – period. An attacker doesn’t need your root password to read/exfiltrate your data or establish persistence. They do not need it at all … for anything of value.
Looking at my own network connected qubes, they fall into one of these four categories:
-
Highly specialized web qube (e.g. banking, amazon, medial); nothing gets stored here; if this gets compromised the attacker can watch me use the service they already compromised in the first place in order to attack me; some of them are limited to a specific IP range to make eventual back channels even harder … but then again: what is there to exfiltrate in the first place?
-
Single purpose qube for a specific protocol/use case (e.g. mail → mail servers, hcl → github ip range). These qubes can only talk to a specific service on a specific port. They deal with data that is by definition already available at the services that can be accessed. Granted, this can be improved via qrexec / split implementations
-
general purpose web qube → always disposable (no worries about data stored here or persistence of any kind)
-
proxy qube (e.g. adding VPN tunnel), do data here, connections are encrypted on both ends
If you are worried about an adversary targeting you specifically and having access to a Xen VM escape 0-day … well I guess: don’t use Qubes OS then. Keep in mind that these kind of exploits are used highly tactically, because once they are used they usually get detected sooner or later and then patched / loose their value. So you must be a pretty high value target for an APT to risk using such a treasure on you. If that is in your thread model: burn your phone and computer and … I have no idea. Good luck! 
Remember the “reasonable” in the tagline?
2 Likes
I still cannot see how you people think about one simple click-through dialog as such an “inconvenience”. You may call it a false sense of security but it gives me a somewhat soothing feeling :))
1 Like
Precisely the point.
Okay, this is good. Somehow I am now understanding the lack of significant protection afforded by a root password in the context of Qubes. I’m not sure what it was you said specifically, but it’s at least clearer now.
I already had a good grasp of the concept of hardening by compartmentalizing. So I suppose the real solution for added security is to deepen that approach, continue to develop my command line chops and learn more advanced system configuration to further isolate certain activity, connectivity and data. Thank you for taking the time to reply.
1 Like
If you nevertheless care about persistence, perhaps you may want to “renew” your qube from time to time by creating a new one (maybe with a different template) and customizing it anew. Details here: Compromise recovery in Qubes OS | Qubes OS.
I think this is a good practice in general… not unlike the general practice of regularly changing passwords.
Well, again;
if you are targeted by something FOXACID-level, then they have LPE and everything for sure.
If you are targeted by an opportunistic attacker, and they happen to have a good exploit chain for Linux and by some chance, Xen, EVERYTHING helps to make the task harder. And getting root is one thing.
Yes, and I would like to have SELinux, too (for Whonix I run it with AppArmor enabled). Why SELinux if is fully irrelevant for browser exploits (the browser always runs non-sandboxed part unrestricted, right?). Just because it is another obstacle for LPE.
What would REALLY help but requires whole different effort? DETECTION. Something like one-machine-SIEM to manage and monitor all the logs (including auditd and SELinux violations), capture suspicious traffic etc etc. Then we at least could see when something bad happens – and letting the attacker know that we know would repel the majority of attacks of this type :)))
Within the Qubes architecture, disabling passwordless-root alone does not buy one much additional security.
However, it is an optional package. So…you can uninstall it from a template or standalone VM if you wish. As has been stated before, it’s not installed in the minimal templates (…and that constantly leads to support questions! 
).
So…if one has very particular needs about detecting and/or deterring attacks within particular VMs, beyond the protection that compartmentalizing gives, feel free to disable it or configure the sudo/ask method.
And…if you must be in that paranoid and/or defendably-defensive realm, you should check out @tasket’s project here to see if would be helpful w/r/t your threat landscape: GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup
Brendan
Hardening is not easier/safer than not keeping sensitive data where they shouldn’t reside.
2 Likes
My questions are mostly a matter of learning - more than a need for extreme security per se. But if a particular countermeasure isn’t terribly inconvenient, why not? I do like to make everything as secure as possible within reason. tasket’s project looks excellent. Thank you!
The other way I found as simple and convenient for myself, the root terminal hotkey for xbindkeys, to start xterm in current (focused) AppVM:
"xprop -id $(xprop -root | awk '/_NET_ACTIVE_WINDOW\(WINDOW\)/{print $NF}') | awk -F '"' '/_QUBES_VMNAME\(STRING\)/{print $2}' | xargs -I{} qvm-run -u root {} xterm -e /bin/bash"
Shift+Mod3 + Return
Of course you should remove the qubes-core-agent-passwordless-root package.
And then, if you really really need to start a root programs from user, you can paste something like that to /rw/config/rc.local file:
echo "
user ALL=(root) NOPASSWD:/usr/sbin/nethogs
" >> /etc/sudoers