Selective `sudo` Access Enabling in VMs Without `qubes-core-agent-passwordless-root` via `qvm-service`

adrelanos commented 2 days ago

The problem you're addressing (if any)

In Qubes OS, when the qubes-core-agent-passwordless-root package is removed from a template, App Qubes based on this template lose sudo access, which is the intended behavior for enhanced security.

The typical method of gaining root access in such cases is by using qvm-run -u root vm-name xfce4-terminal, allowing access to a root shell. However, working directly as root presents limitations:

GUI applications may not work properly when run as root. For instance, editors like kate may refuse to run as root, and others might exhibit inconsistent behavior.
Running processes as root can lead to unintended changes in permissions within the user's home directory, causing problems later.

Ideally, I would like to add the user user to the sudo group to gain root privileges when necessary, without these drawbacks.

However, after running sudo adduser user sudo in the root shell, a re-login or reboot is required for the group membership changes to take effect (which is standard in Linux systems). In Qubes OS, this becomes impractical because:

Reboots into App Qubes do not persist the change, as the /etc/group file resets. Thus, adding the user to the sudo group is lost after a reboot.
Alternatives like su and newgrp are unavailable due to SUID security hardening (SUID removal) in Kicksecure.

The solution you'd like

Introduce a qvm-service option to control sudo access in a VM.

This could be added via Qubes VM Manager (QVMM) → VM Name → Settings → Services → Add sudo. This would enable sudo access for the user in the VM without relying on the qubes-passwordless-root package.

Technically, this would work by having a systemd unit that runs before "login inside the VM" to execute adduser user sudo. This way, sudo privileges could be granted to the user at VM startup without requiring reboots, re-logins, or direct modifications to the template.

The value to a user, and who that user might be

This feature would be valuable for Qubes OS users who prefer not to install the qubes-passwordless-root package but still need to selectively enable sudo access in certain VMs. It would provide a flexible and lightweight way to grant sudo access per-VM selectively.

Alternatives considered

Maintaining Two Templates: One with qubes-passwordless-root installed and one without. While functional, this approach introduces significant overhead and complexity, especially for users managing many Templates.
Manual Methods: Manually adding users to sudo each time a VM starts, though this is inefficient and requires repeating the process every time due to lack of persistence. Also I haven't even found a way on how to do that yet.

unman commented 2 days ago

Is it not simpler to add usermod -a -G sudo user to /rw/config/rc.local?

adrelanos commented 1 day ago

I should have mentioned... Earlier I tried adduser user sudo in /rw/config/rc.local. That did not work for me. usermod -a -G sudo user should be the same and does not work for me either.

This might be happening because /rw/config/rc.local is maybe parsed only after "login".

An alternative fix to suggest would be: "parse /rw/config/rc.local before login" but then that could break other unknown use cases.

An alternative feature request would be: "implement /rw/config/rc.local-pre-login" (so the adduser command to add user to group sudo could be executed before "login""

adrelanos commented 1 day ago

(Edited/fixed wrong path in above comment.)

marmarek commented 1 day ago

https://github.com/QubesOS/qubes-core-agent-linux/pull/386 might allow implementing it this way

marmarek commented 1 day ago

Alternative implementation: #2695 (then it's up to the policy: always allow, ask, deny)

unman commented 1 day ago

On Thu, Oct 17, 2024 at 12:17:51AM -0700, Patrick Schleizer wrote:

I should have mentioned... Earlier I tried adduser user sudo in /rw/config.rc.local. That did not work for me. usermod -a -G sudo user should be the same and does not work for me either. It might be helpful if you could say in what way it "does not work". It works for me with debian-12-minimal template based qubes, allowing use of eg sudo su.

The sudo group is present in minimal templates. Why can you not leverage that?

adrelanos commented 21 hours ago

It might be helpful if you could say in what way it "does not work".

user gets added to group sudo but a terminal running as user (started from Qubes start menu) still cannot use sudo. Group changes did not take affect. I would guess because it happened after "login".

Using su would be required beforehand. (But that is disabled due to SUID hardening and also cumbersome.)

As for the mixed results, I am expected a race condition. What happens first?

user addgroup to sudo before "login" -> functional
user addgroup to sudo after "login" -> broken

QubesOS / qubes-issues