Automate vm sudo authorization setup

[tasket]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

All Linux

---

General notes:

Users wishing to enable dom0 prompts for domU sudo authorization must edit several config files according to doc/vm-sudo...
https://www.qubes-os.org/doc/vm-sudo/

Since this configuration has worked well for many months with only one (fixable) sticking point, I figured the setup could be automated with a script provided by Qubes. This would allow the user to choose the sudo mode without being mired in the technical configuration process.

---

Related issues:

#2693

[andrewdavidwong]

It's unclear to me whether @rootkovska and @marmarek would want Qubes to offer or support such a script.

[rootkovska]

Well, if the service for qubes.VMAuth is really to be comprised of /usr/bin/echo 1 only, then I don't see how this could weaken the security of Dom0 or anything. I'd worry more about sending a false-sense-of-security signal that (presumably) Dom0 is able to strictly control user -> root escalations within VMs (which it really cannot 100% as explained in the linked page). This might also lead to some people insisting we should be releasing QSBs for intra-VM escalations (which we don't want to do).

[rootkovska]

Other than that, I admit I kind of like the simplicity of this proposed 1-liner qubes.VMAuth service and how it illustrates the power of qrexec :)

[tasket]

I'd worry more about sending a false-sense-of-security signal that (presumably) Dom0 is able to strictly control user -> root escalations within VMs (which it really cannot 100% as explained in the linked page). This might also lead to some people insisting we should be releasing QSBs for intra-VM escalations (which we don't want to do).

@rootkovska Very understandable, since VM isolation must remain the paramount organizational principle for Qubes (both in terms of code and motivations). I'm actually glad the community has been able to evolve without the conventional security mindset. Yet, spotty as guest OS security is, in Qubes it represents a measure of security offered but not taken, even though Qubes integration makes it resemble the ease of Windows UAC. There is also the question of whether our VMs appear to be easily-acquired resources for attackers (i.e. the 'welcome mat' layed out), which promises to be at least a nuissance factor in operations.

I think it also makes sense to offer this kind of configuration script to accompany the grsecurity configurations that more of us Qubists will soon be using.

The script should print a pointed disclaimer (with agreement prompt) that Qubes Project cannot vouch for the results or efficacy of the VMs' internal security--that, indeed, dom0 does not maintain strict control in any domU as you say. To allay your fears, realize its already routine for a Qubes user to think this way when using similar dom0 prompts to authorize qvm-copy tasks, etc.

Other than that, I admit I kind of like the simplicity of this proposed 1-liner qubes.VMAuth service and how it illustrates the power of qrexec :)

Its quite cool in terms of UX, also.

[rootkovska]

I've been recently talking about this with Solar Designer of Openwall (a person who probably knows more about Linux security model than most of us together), and below I try to summarize the outcomes of our discussion:

1. The primary reason to even consider any kind of root account isolation within Qubes AppVMs is to make it more difficult for attackers to launch attacks against Xen (most, or perhaps all of the XSAs that affected Qubes required root in the VM).

2. This "protect Xen" goal is significantly more important that any kind of in-VM isolation, e.g. ability to run different apps as different user accounts. Indeed, current Xorg doesn't make this feasible architecturally even, and in fact it's been one of the Qubes fundamental goals to fix this (long before anybody started even talking about Wayland that apparently also tries to fix this).

3. The obvious problem with using any kind of control mechanism for sudo, such as the one proposed in this ticket, is that once we open a root console in the VM, it still runs under the same Xorg that is being used by non-root apps in that VM and these other apps can launch a number of attacks against this already opened root console, such as keystroke injection to name the most obvious. Again, one of the goals of Qubes is to fix this problem by... introducing the concept of an AppVM. However, given that our goal is currently: not allowing attackers to get root in the VM, we need something else...

4. A solution proposed by Solar is to start another Xorg in the VM -- as root -- whenever the user decided he or she want to start a root shell in the VM. While in principle there is nothing that should prevent this, in practice there will likely be lots of minor PITAs with this. E.g. both our GUI agent and daemon have been written with assumption that for each AppVM there is only one daemon (in dom0) and one corresponding GUI agent (in the VM), which results in some sockets/vchan ports being hardcoded in the code.

5. A potentially alternate solution might be to not use GUI virtualization for performing any root operations in the VM. Indeed, one can use qvm-run -e root -p to get "raw", shellcode-like access to the VM. But not having a real PTY means this cannot be used e.g. to run vim or any other curses-based app. And of course WE DO NOT WANT to pipe the output of qubes.VMShell (which is what qvm-run uses) to an actual PTY-implementing code, for this would likely be a security disaster.

6. So, it seems that the option with starting the 2nd Xorg for the root user seems the most secure solution (+ disabling sudo for user). Unfortunately at this moment we (ITL core team) do not have resources to work on this...

7. Still it might be worthwhile to enable this sudo qrexec-authorization by default for our default template, after all. This is maybe because for many AppVMs there will never be a need for user to start root shell. Indeed, if we think why a user might want a root shell (see below), then it might turn out that often there should never be a need for starting root terminal in VM, and this could then be easily achieved by what is proposed in this ticket.

8. So, why a user might want to start a root terminal in a VM -- here is some initial list:

• customize some scripts in /rw/config (typically in "devel" VMs)
• run docker in VM (typically only in "devel" VMs, where builds run)
• run gdb, tcpdump, nmap, etc (also typically in "devel" or "admin" VMs)

[solardiz]

Joanna, thank you for summarizing this so nicely! (Even though I think you overestimate my knowledge as it compares to your community's.)

Regarding point 5, another concern is that a typical user would run the qvm-run command from a terminal that supports escape sequences (even if their intended use without a PTY inside the VM makes little sense) - and this opens up significant attack surface on Dom0 for attacks from the VM.

Regarding points 7 & 8, and what's proposed in this ticket, another concern is that this requires keeping sudo (or equivalent) available from the user account, which severely limits the extent of userland hardening that can be implemented. Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)

That said, I am fine with the interim change proposed in here, hoping we'll have a more extensive solution (such as per point 4) implemented in not too distant future.

If going for two Xorg's per AppVM soon is unrealistic, then maybe we can run the only Xorg as a second pseudo-user (almost root) and have terminal started (when requested from desktop environment menus and such) as that pseudo-user (which can sudo to root without password)? This wouldn't avoid the obvious problem of point 3, but it would make points 7 & 8 (rare use of privileged shells) more relevant since the userland could be hardened to a greater extent (no SUIDs available from the user account that most apps run as). It would also avoid the complexity of having VMs talk to Dom0 for authorization.

[tasket]

Many good points here.

I would just like to reiterate the original idea from my perspective: Linux distros utilize certain tools for security, so it makes sense to let them work and have the distros patch holes, move to wayland, etc. as they usually do. I think this goes for guest graphics layers occupying a security role as much as for guest kernels. That leaves the security characteristics of the guests mainly a consequence of the guest OS, meaning that OS choice is important.

Apart from the possibility of protecting Xen, I feel that offering root capabilities within VMs -- without resistance -- could make Qubes guests attractive resources to attackers of just about any skill level. This has consequences for the computing devices that are connected to our vaunted Qubes PCs. If everything ran a Qubes-like OS it wouldn't be a big deal, but in 2017 that is very far from reality. IOW, the current approach is naive and needs revision, even if Xen can fend off all attackers internally. If normal guest security is enabled, then at least Qubes does not stand out as a particularly hospitable attack platform.

Of course, another point was that the measure is low cost to Qubes. For the same reason, I'd recommend people stick with hardening approaches that are either simple or supported by the guest distro.

As for ideas on mitigation... Joanna's points 5 & 8 are resonating with me. Why not have template-based VMs that default to no root access at all from su or sudo? Or mirroring the firewall that allows sudo access for X minutes? Users could still access root in templates, or in selected VMs that have the feature enabled (and there is still qvm-run -u root).

[cfcs]

I think the "second Xorg" solution sounds like the way to go.

I would like to repeat my suggestion to either mount as much as possible with -o nosuid while we are at it, or strip sgid/suid from all binaries in /. The latter approach suffers from the problem that installed packages can introduce new suids.

An obvious example of why this would be nice is that even if we disable sudo completely (sudo being restricted to the members of the sudo group by default -- which currently only contains the default user account), any uid in the machine can run commands as root with pkexec, as people have demonstrated on IRC numerous time when this subject has come up.

EDIT: My point being that keeping track of crazy linux suids is not a fun task.