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.

[cfcs]

I found the example posted on IRC:

$ sudo -u myuser -s pkexec id
uid=0(root) gid=0(root) groups=0(root)
$ sudo -u myuser -s sudo id
uid=0(root) gid=0(root) groups=0(root)
$ sudo -u nobody -s pkexec id
uid=0(root) gid=0(root) groups=0(root)
$ sudo -u nobody -s sudo id
* asks for password *

[solardiz]

@tasket Most of what you wrote makes sense to me (even if I don't necessarily prefer this specific model), except for the "Apart from" paragraph, which I think either has flawed logic or is somehow unclear to me. What do you mean by "computing devices that are connected to our vaunted Qubes PCs" and why would it matter to the attacker whether they have root in the VM or not? (Aside from attacks on Xen.)

[tasket]

Reflecting on having no su or sudo in appVMs and my own usage patterns, I think this would make it necessary to run template VM at times when I normally wouldn't. Or perhaps use a sudo-enabled standalone VM for trying out new (admin/dev) ideas where I would otherwise try them temporarily in one of my appVMs. The change to me would not be big.

[solardiz]

@cfcs "any uid in the machine can run commands as root with pkexec" is part of current setup on Qubes, similar to sudo. PolicyKit's policy would be changed at the same time with a possible change to the sudo policy.

A bigger concern is that all of those programs, and the libraries and kernel interfaces they expose to attack, contain bugs. This is why we should aim for no SUIDs reachable by the user account that most apps run as. The nosuid option is fine for this if we can afford it for the entire system; otherwise we need to harden file permissions.

[cfcs]

@solardiz agreed on all points, with the note that currently sudo is at least somewhat hardened.

[tasket]

@solardiz I think it matters to attackers because we're providing them with a ready-made environment without the need to upload their own tools that may not even work correctly. That also makes their presence harder to detect. Normal privs also provide a basis for restricting net access according to process, user or group which qubes-firewall cannot do.

@cfcs I'd be against a re-engineering of guest security, as that means more work and vigilance required from Qubes project... in addition to the project being responsible for related breeches.

[marmarek]

On Sun, May 14, 2017 at 11:55:25AM -0700, tasket wrote: @solardiz I think it matters to attackers because we're providing them with a ready-made environment without the need to upload their own tools that may not even work correctly. That also makes their presence harder to detect. Normal privs also provide a basis for restricting net access according to process, user or group which qubes-firewall cannot do.

If attacker can reach sudo, or other suid process (-> have shell access), it's already game over for this VM. But we can still make it harder to break out into other VMs. But before the shell access, there are a lot of kernel mechanisms that can make it harder to exploit application bugs. This include grsec (oh well...), and similar.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[cfcs]

@tasket In that case I don't understand why you filed this issue. If you're not open to discussing the security configuration of AppVMs, what are you trying to accomplish with this discussion?

I am telling you that the configuration of sudo has no consequence whatever to neither malicious nor benign use cases when there exists binaries such as pkexec (and a plethora of other strange ones) that serve the exact same purpose, but that do not currently require any of the prerequisites of using sudo.

I then offered a simple potential one-line solution, and now you are telling me off?

in addition to the project being responsible for related breeches.

I would be extremely curious to hear what kind of breaches you expect that the enabling of nosuid on the filesystems would further expose the user to that cannot already be executed today. Literally, tell me how it can get any worse.

[tasket]

@marmarek

If attacker can reach sudo, or other suid process (-> have shell access), it's already game over for this VM.

This seems like a reason for protecting shell startup scripts as in Qubes-VM-hardening as that's the glaring barrier I see to running auth programs correctly (note this also matters for non-suid programs that handle authentication!), but otherwise we should assume users and user apps will have shell access... whether or not suid programs are available.

@cfcs Maybe mounting with suid will be easy and effective (doing this for root fs or particular files, and impact on desktop components like pulseaudio... I have to wonder), but adding another X11 is not going to be easy and it represents an additional procedure call complexity between dom0 and domUs. Please don't take it personally, I just don't like the extra-X idea for reasons Joanna stated.

As for various suid programs like pkexec, they hinge on policykit auth settings which are covered in the vm-sudo config (i.e. removing the Qubes settings for permissive access)...

$ sudo -u user -s pkexec
<dom0 auth prompt, answer Yes>
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

I see the choice as being between removing the Qubes guest auth modifications (i.e. vm-sudo doc) or disabling user->root access (whether by PAM, policykit, mount options, etc). Even when choosing the latter, it wouldn't affect users very much if access could be enabled for specific VMs.

[marmarek]

@adrelanos does Whonix rely on passwordless sudo access configured in Qubes by default, or everything is covered by own files in /etc/sudoers.d?

[adrelanos]

Marek Marczykowski-Górecki:

@adrelanos does Whonix rely on passwordless sudo access configured in Qubes by default, or everything is covered by own files in /etc/sudoers.d?

It should be sorted out in Whonix 14.

Whonix 13 required changes required here:
https://www.qubes-os.org/doc/vm-sudo/

//cc @tasket (who did that commit)

[marmarek]

As Joanna stated above - we do want to make this sudo authorization setup easier. The first step is splitting passwordless root access configuration into separate (opt-out) sub package. As Whonix do not install recommended packages by default, it may mean that by default Whonix will not have it... So, it will need similar solution as in #2572 (comment)
As for actual sudo configuration - I see several files in /etc/sudoers.d have commands with * as argument. If in practice the command is called only with one or two specific arguments, IMO it's better to be verbose here.

[adrelanos]

Quote @marmarek #2695 (comment)

As for actual sudo configuration - I see several files in /etc/sudoers.d have commands with * as argument. If in practice the command is called only with one or two specific arguments, IMO it's better to be verbose here.

Created #2852 for it.

[marmarek]

Why "I" can do it but user "man" cannot? What makes "me" and user "man" different?
On non-Qubes Debian I am always wondering if I can switch a virtual console using ctrl + alt + F1, why can user "man" not? And how's that different in Qubes?

This is about where the process is started and what has connected as controlling terminal. It isn't anything Qubes specific. A non-privileged process cannot inject characters into a separate session (lets forget about X11 breaking all this assumptions, as we are talking about non-X11 session), especially if it's of a different user, similarly as it cannot write to files it doesn't have write permission. to. You can think of it as a write access to /dev/tty* (or /dev/hvc0 in this case). When you login on /dev/hvc0, login process (running as root) will setup permission to /dev/hvc0 and also pass an open FD to it to your shell. Then, you (user, and that shell) will be able to interact with /dev/hvc0 and specifically run commands connected to it. If you don't login there, login process will not set the permissions, so you won't have access.
This does assume kernel enforced permissions are effective, but as we are talking here about in-VM account isolation only, it's a reasonable assumption.

[andrewdavidwong]

This does assume kernel enforced permissions are effective, but as

I think maybe the end of your sentence was cut off, @marmarek.

[marmarek]

I think maybe the end of your sentence was cut off, @marmarek.

Yes, thanks, updated.

[adrelanos]

@marmarek

(lets forget about X11 breaking all this assumptions

Indeed.

While experimenting with module loading disabling, I experienced that broken X can block switching to virtual console. Needless to say (for other readers), if X can do, also malware could do. "SysRq + r" can take away control from X. After that, switching to another virtual console was possible.

[marmarek]

Yes, X (or other process with access to input device) can grab it for exclusive access, disabling Alt+Ctrl+F1 or similar combos. This still is independent of what is happening on other terminals. Especially, input devices grabbed in this mode are handled by X server (or other process that grabbed them). As long as X server doesn't have access to other terminals, it still can't influence them.

[DemiMarie]

• 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.

Since then, a safe solution for this has appeared: qvm-console-dispvm and the admin.vm.Console service. This allows one to log in as any user (including root) on a secure Xen TTY. The actual terminal emulator is sandboxed in a disposable VM.

[adrelanos]

For some VMs should never even show a sudo prompt. A VM supposed to only run a browser has no reason to show a sudo prompt. Maybe you can show a notification but without option to accidentally confirm. Just as a notification that something is probably wrong. Because such a VM normally if not compromised or something unexpected running automatically should have no reason to ever use sudo.

Which VMs can vs cannot use sudo should actually be on a whitelist, opt-in basis.

• default: no sudo
• opt-in: sudo prompt or always sudo access

Ideally that would be a Qubes dom0 qvm-prefs and Qubes VM Manager (QVMM) setting.

[adrelanos]

@solardiz

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.)

SUID Disabler and Permission Hardener has been created thanks to your suggestion.

@cfcs

I would like to repeat my suggestion to either mount as much as possible with -o nosuid while we are at it,

This is best handled in dedicated tickets. Check linked tickets / open tickets / please new tickets for mounts, should there be no ticket yet.

or strip sgid/suid from all binaries in /.

This is done in SUID Disabler and Permission Hardener as much as possible. At time of writing, only installed by default in Kicksecure and Whonix. It should however be possible to re-use it in Debian and might even be possible to port it to other Linux distributions.

There's however configuration default folder /usr/lib/permission-hardener.d, which contains a whitelist of SUIDs, which are still required, for reasons documented in these configuration files.

The latter approach suffers from the problem that installed packages can introduce new suids.

SUID Disabler and Permission Hardener handles that as well. It disables all SUID / SGID by default, except if these have an explicit configuration file which whitelists these. This is implemented using a DPKG trigger ("APT post installation hook").

All things SUID for Qubes should probably be moved to a dedicated ticket.

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.

SUID Disabler and Permission Hardener handles other privilege escalation tools as well (sudo, su, pkexec) if user-sysmaint-split is installed. This accomplishes the goal No Access to Privilege Escalation Tools for Limited Accounts.

This I would also suggest for this Automate vm sudo authorization setup ticket too. If this gets implemented, privilege escalation tools SUIDs should be inaccessible to limited user accounts.

[DemiMarie]

@adrelanos: What about the /dev/xen/* permissions issue? There are three ways I can think of to solve that:

1. Add Xen support to AF_VSOCK or a similar kernel API.
2. Make the various Qubes tools that use /dev/xen/* setuid root.
3. Split the tools into privileged daemons and unprivileged command-line tools.

The GUI agent is going to be especially tricky. Since the X11 client libraries are not secure against malicious servers, this might require that the X server run as root for the GUI agent to work. This in turn runs into problems with the X server, which is badly maintained. The long-term solution is to transition to Wayland, but that has its own problems and will take a while.