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.

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

[adrelanos]

Will answer in dedicated ticket:

• harden insecure permissions inside /dev/xen folder / research security impact of the Qubes /dev/xen folder permissions #9717

[HW42]

I'm currently working on packaging this.

On the technical side: Calling qrexec-client-vm (or a script that doest that) via pam_exec, seems rather brittle since this is all running in the setuid context of sudo. Since there the unprivileged caller can control part of the execution environment that is easy to mess up. So instead I'm replacing this with a very simple PAM module that doesn't spawn subprocess.

On the UI side there are still some open questions:

How should this be en-/disabled? Just by (de)installing a package (something like qubes-core-agent-root-via-dom0-auth)? Or by qvm-feature, or config file?

The qrexec "ask" prompt used for authorization is rather ugly from a UI perspective. You basically need to understand the implementation detail to know why it's asking for a target VM at all, why it's dom0 and why it's not risky (granting a prompt that talks about admin access and dom0 sounds pretty scary. Maybe we should spawn a custom prompt in the qrexec service instead of repurposing the qrexec ask prompt?

[marmarek]

On the architecture level I'd prefer to keep it a qrexec prompt, as it avoids duplicating a bunch of effort (handling GUI VM, configuration when to prompt etc). As for the prompt itself, indeed it's not great. Maybe it could be the first case for #5853?

[ArrayBolt3]

I believe Whonix has some interest in this now, since this ties closely into the "selective sudo access" feature request previously made by @adrelanos. Personally, I think it would be best if this feature was not simply packaged, but rather used to replace qubes-core-agent-passwordless-root entirely. qrexec can be used for authorizing all privilege escalation attempts through sudo, su, and pkexec, with the allow/ask/deny behavior used to decide what is permitted or not as @marmarek pointed out in #9512 (comment).

@HW42 Let me know what you think of this, this is on my todo list as a high priority thing I need to be implementing, but I don't want to duplicate work and end up with two competing implementations of the same thing.

[ArrayBolt3]

On the architecture level I'd prefer to keep it a qrexec prompt, as it avoids duplicating a bunch of effort (handling GUI VM, configuration when to prompt etc). As for the prompt itself, indeed it's not great. Maybe it could be the first case for #5853?

@marmarek Not a bad idea! Are these prompts implemented in Qt? I'm rather handy with it and could probably take a swing at implementing that or some of it. If it's GTK, then I'm less handy with it, but still willing to give it a shot if it will help move this forward.

[marmarta]

the prompts are implemented in Gtk, but frankly if we could move away from it towards a Qt-based it wouldn't be bad (Qt is more long-term maintainable, I think, because each new Gtk version tends to obsolete without replacement a bunch of stuff).

[marmarta]

So, what does everyone think about the following idea for a UI for this?
(mildly) clickable prototype: https://design.penpot.app/#/view/37d6e7bf-72f9-806c-8005-b60cb04ba20d?page-id=37d6e7bf-72f9-806c-8005-b60cb04ba20e&section=interactions&index=0&share-id=02968425-bc48-80f1-8005-b62d69659356

screenshots:

[marmarta]

Ideally, there would be a separate dark/light mode UI, with the following for dark mode:

[ArrayBolt3]

The design is nice, I like it a lot. Light/dark mode support is pretty easy with Qt (a lot of times it will do all the hard work for you). Something similar to this could be used for the other prompts too.

The wording feels a bit off to me. "test-qube has requested root access" sounds like "test-qube" is trying to gain root access in some other VM. When you look at the request details and see dom0 is the target, it sounds like the qube is trying to take over dom0. The "in this qube" bit is easily missed, and may still sound like it's trying to take over dom0. Especially if this was popped up in response to someone trying to run sudo, I think that might be alarming. The wording should IMO convey that it's an app in test-qube requesting root access in test-qube. A way to do that clearly without saying "test-qube" twice is eluding me at the moment though. Maybe something like this would work?

An application in `test-qube` would like root access in `test-qube`. Would you like to permit this?

v Show request details

   Source: test-qube
   Target: dom0
   Service name: qubes.AuthorizeInVMAdminAccess
   Argument: (none)
   For more information about these details, click [here].

[Allow root access] [Cancel]

My idea with the click [here] is to allow users to verify for certain that dom0 is the VM providing the go-ahead, not the VM that access is going to be granted to. Even that still leaves the user with the initial scare though, and then tells them to not panic after they're already panicking, Given how scary Target: dom0 is, part of me wonders if we shouldn't just hide that from the user since it doesn't matter anyway, the "target" will always be dom0 in this instance. I'm not a fan of hiding info from the user, but I'm not sure there's a good way of doing this otherwise.

[marmarek]

The details are collapsed by default. But IMO it's important to have that part available, and have reliable info, as that's what you need if you want for example to adjust the policy, or understand why you got this prompt exactly (correlate with logs etc).

[marmarek]

The call target requested by the qube may be @default (and accepting the call would then accept it to dom0) - that may look less scary maybe? But that needs checking, don't remember which info the prompt agent has access to.

[ArrayBolt3]

@marmarek Good point about the technical details being needed. Maybe it would be possible to just show the service name where there's currently "request details" and then allow viewing the full list of things using a "debug info" button?

[HW42]

@marmarta:

So, what does everyone think about the following idea for a UI for this?

In general looks very much like what I want, except I think the actual text needs to be reworded. Something in the direction of: "Inside test-qube the user wants to execute a command with admin privileges. Do you want to allow it?"

(Not sure if we want to use "admin" or "root" in the UI. For non Linux system it might not be named root)

A link to the docs would be great too, so that we can document details there like that in-qube privileged separation is somewhat out of scope, etc..

---

@ArrayBolt3:

@HW42 Let me know what you think of this, this is on my todo list as a high priority thing I need to be implementing, but I don't want to duplicate work and end up with two competing implementations of the same thing.

Please wait a moment, there should be something for you to review in the next days.

[HW42]

The title of the custom prompt it should say "in-qube" instead of "qube".

[ArrayBolt3]

@HW42 Sounds good. I'll keep researching some stuff in the mean time, but will wait to write any real code while you're working on this. Thank you btw!

[marmarta]

The text definitely needs to be reworded, of course :) I would prefer putting the qube at the beginning of the message, because especially people who have seen it a bunch of times will just jump to seeing if the qube is what they expect it to be, plus if we ever do translations it will be easier to do, but I admit it might not be doable.

Maybe:

• test-qube: an application requested root access within this qube. \n Do you want to allow it?
• test-qube: an application attempted to access admin privileges. Do you want to allow it?

WRT to dark mode: a thing I put there is coloring the VM name with the VM color, to enhance recognition modes; except that it has to be adjusted to the dark/light mode, because e.g. green-that-is-readable-on-dark-background and green-that-is-readable-on-light-background is not the same green. When you get to implementing it, please ping me, I'll do a color table for existing VM colors (also me fantasizing about making the vm label object know things like that :D)

[marmarta]

Could we know which application requested that? (That would make the prompt clearer, I guess?)

[HW42]

Maybe:

* `test-qube: an application requested root access within this qube. \n Do you want to allow it?`

Sounds ok, although I usually wouldn't use the term application for a tool like sudo.

* `test-qube: an application attempted to access admin privileges. Do you want to allow it?`

Here the "within qube" aspect is missing.

Could we know which application requested that? (That would make the prompt clearer, I guess?)

To some extend yes, but I don't think that's a good idea. Same applies for the command that is being executed.

Why? This adds a lot of complexity with little value. Anything running as user user could fake a plausible sounding application name. Also many commands people run via sudo allow permanent privileged escalation (spawning a shell, executing other code as root, etc.), so showing only the invoked command is rather misleading.

[marmarta]

Sounds ok, although I usually wouldn't use the term application for a tool like sudo.

a program, then?

To some extend yes, but I don't think that's a good idea. Same applies for the command that is being executed.

Why? This adds a lot of complexity with little value. Anything running as user user could fake a plausible sounding application name. Also many commands people run via sudo allow permanent privileged escalation (spawning a shell, executing other code as root, etc.), so showing only the invoked command is rather misleading.

Ok, then it's not a great idea, scratch that.

[ArrayBolt3]

@HW42 Gentle ping, how are things coming along? If there's anything I can help with, I'm happy to.

[HW42]

@ArrayBolt3:

I believe Whonix has some interest in this now, since this ties closely into the "selective sudo access" feature request previously made by @adrelanos. Personally, I think it would be best if this feature was not simply packaged, but rather used to replace qubes-core-agent-passwordless-root entirely. qrexec can be used for authorizing all privilege escalation attempts through sudo, su, and pkexec, with the allow/ask/deny behavior used to decide what is permitted or not as @marmarek pointed out in #9512 (comment).

Is managing this via qrexec policy as suggested there enough for your use case or is some setting at the template level needed too? For users managing things via qrexec policy should work great, but it has the limitation that this is basically out of control of (and not visible to) a template. So for example an "hardened" template can't easily change the default for itself and VMs based on it. As long as we keep this in a separate package like qubes-core-agent-passwordless-root, the template at least can fully opt-out by uninstalling it, but nothing more finegrained.

[ArrayBolt3]

@HW42 Probably template-level control is also needed, along with the ability for the user to customize the policy via the GUI (setting a per-VM "Allow, Ask, Deny" switch via Qubes Manager). I was intending on implementing basically the entire stack of things needed to make that work, including the changes to the qrexec prompts to make them pretty. If that's not your goal, that's fine, I'll just build from your work once it's done, unless you see a potential conflict here.