Personally, I don’t use passwordless root because I have a very easy keybind (through i3-qubes-sensible-terminal to launch root terminals in any qube. If I did not have that, I would probably use passwordless root.
I read Passwordless root access in qubes — Qubes OS Documentation and even although I think I get Joanna’s POV, I still think, especially in critical sys-vms (like sys-net) that passwordless-root could be potentially quite dangerous. An attacker with root access in sys-usb or sys-net (even without breaking out of the VM) could still potentially cause quite some damage.
Ie. An attacker could reconfigure local services, change / observe firewall rules, or alter local monitoring, access / alter USB drives or network controllers, also allowing software/malware that would normally be bound by user would suddenly, easily have root access/privileges (which could then expose a whole new range of bugs / malware)?
After fully reading Joanna’s argument again, it is very clear what the issue is, they are assuming their stated threat model is the same for everyone, so the Qubes OS team has assumed it since:
# 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).
They are treating the two as separate issues, but they are highly intertwined, that is exactly what privilege escalation is. By explicitly eliminating the friction between user and root, an attacker is more likely to successfully achieve compromising the hypervisor.
# One might argue that some hypothetical attacks against the
# hypervisor or the few daemons/backends in Dom0 (so VM escape
# attacks) most likely would require root access in the VM to trigger
# the attack.
#
# That's true, but mere existence of such a bug in the hypervisor or
# Dom0 that could be exploited by a malicious VM, no matter whether
# requiring user, root, or even kernel access in the VM, would be
# FATAL. In such situation (if there was such a bug in Xen) there
# really is no comforting that: "oh, but the mitigating factor was
# that the attacker needed root in VM!" We're not M$, and we're not
# gonna BS our users that there are mitigating factors in that case,
# and for sure, root/user isolation is not a mitigating factor.
Their argument is conflating roles with capabilities. Even if Xen and dom0 were wide open, roles and their capabilities in each guest VM define what has access to them. If an attacker does not have any capabilities in their assigned role in the VM, they cannot do anything to escalate to a role with more capabilities.
I don’t know, but it seems to me they are saying we can leave the front door to the house unlocked because if someone is able to get in there they will only have access to the front room.
There also seems to be some strange argument that says, well if an attacker can be that skilled then sudo / root escalation is trivial therefore not worth enforcing at all.
# 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).
Well I am here to try to gather information first.
To see if others have addressed this and thought about it. Which is why I started this thread.
I am most certainly missing some information here.
I hope this is a non-question that Qubes devs are already confident that the architecture is solid, but the more I think about it, (and read about it) the less I trust it.
I guess I would probably change my workflow if I did not trust qubes-core-agent-passwordless-root but then to what?
I am using 90% minimal templates. However I did install passwordless-root on them. Now I am considering removing that and re-evaluating it.
I may add, I did learn a bit about polkit from that link. That was also a package that I installed in many of my minimal templates. Wow!
# Currently this still doesn't work as expected, because some idotic
# piece of software called PolKit uses own set of policies. We're
# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
# simple experiment: start 'xinput test' in one xterm, running as
# user, then open some app that uses PolKit and asks for root
# password, e.g. gpk-update-viewer -- observe how all the keystrokes
# with root password you enter into the "secure" PolKit dialog box can
# be seen by the xinput program...)
#
I don’t see a reason not to use passwordless sudo on Qubes at the moment, as long as it’s rather easy to escalate privileges anyway, for example by using X11 to write to a graphical root terminal or by using /dev/xen to escalate privileges. Access to the latter is needed due to the way qrexec is implemented. This is also my biggest pain point with Qubes, since you are basically forced to limit yourself to the one layer of isolation Qubes OS provides.
