-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Selective sudo
Access Enabling in VMs Without qubes-core-agent-passwordless-root
via qvm-service
#9512
Comments
sudo
Access Enabling in VMs Without qubes-passwordless-root
via qvm-service
sudo
Access Enabling in VMs Without qubes-core-agent-passwordless-root
via qvm-service
Is it not simpler to add `usermod -a -G sudo user` to /rw/config/rc.local?
|
I should have mentioned... Earlier I tried This might be happening because An alternative fix to suggest would be: An alternative feature request would be: |
(Edited/fixed wrong path in above comment.) |
QubesOS/qubes-core-agent-linux#386 might allow implementing it this way |
Alternative implementation: #2695 (then it's up to the policy: always allow, ask, deny) |
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?
|
Using As for the mixed results, I am expected a race condition. What happens first?
|
I can only say that with a debian-minimal template, this works for me.
(No race condition - it works every time.) I use it sometimes for other
users and none of them report the problem you have.
Again, what template have you tested with?
If you start the AppVM, and open a terminal, what error is reported when
you try to use sudo su?
|
Does it work reliably if you add a |
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 losesudo
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:kate
may refuse to run as root, and others might exhibit inconsistent behavior.Ideally, I would like to add the user
user
to thesudo
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:/etc/group
file resets. Thus, adding the user to thesudo
group is lost after a reboot.su
andnewgrp
are unavailable due to SUID security hardening (SUID removal) in Kicksecure.The solution you'd like
Introduce a
qvm-service
option to controlsudo
access in a VM.This could be added via Qubes VM Manager (QVMM) → VM Name → Settings → Services → Add
sudo
. This would enablesudo
access for theuser
in the VM without relying on thequbes-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 enablesudo
access in certain VMs. It would provide a flexible and lightweight way to grantsudo
access per-VM selectively.Alternatives considered
qubes-passwordless-root
installed and one without. While functional, this approach introduces significant overhead and complexity, especially for users managing many Templates.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.The text was updated successfully, but these errors were encountered: