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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

//cc @tasket (who did that commit)

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

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

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

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