Qubes sudo / su / root Hardening - Development Discussion

Patrick · October 16, 2024, 8:58am

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

opened 08:58AM - 16 Oct 24 UTC

T: enhancement P: default

### The problem you're addressing (if any) In Qubes OS, when the `qubes-passw…ordless-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.

Patrick · October 19, 2024, 8:54am

github.com/QubesOS/qubes-issues

create user `admin` by default and add user `admin` to group `sudo` by default

opened 08:53AM - 19 Oct 24 UTC

adrelanos

T: enhancement P: default

### The problem you're addressing (if any) When removing the `qubes-core-agen…t-passwordless-root` package (to develop towards [strong root/user isolation](https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation)), the suggested way to gain administrative rights in Qubes is to run in dom0 something like `qvm-run -u root vmname xfce4-terminal`. This is problematic. Why not use `root`? * `root` cannot open graphical applications such as graphical text editors (for configuration file editing). ** Maybe X11 can be hacked with a ton of environment variables to workaround this. Maybe even Wayland. But it's non-standard and an uphill battle. ** Some applications such as `kate` have even hardcoded (non-configurable) code to outright refuse running as root. * In App Qubes, `root` does not have a persistent bash command history because its `/root/.histfile` is stored in Qubes root image. ** As a result, lengthy commands such as `http_proxy=http://127.0.0.1:8082 https_proxy=http://127.0.0.1:8082 flatpak update` are lost from the history and need to be re-typed (or copied from somewhere) every time. * `root` has no bash completion by default, which requires even more typing. * Only the action that really requires administrative ("root") rights should use these. Everything else, should be done by a non-root account, even if an administrator with `sudo` access. * Conventional wisdom "do not login as root". * Best security practice. Once/if centralized logging is supported (https://github.com/QubesOS/qubes-issues/issues/830) it's best to use `sudo` to have an audit trail. ### The solution you'd like Create user `admin` by default and add user `admin` to group `sudo` by default. ### The value to a user, and who that user might be Fixes all issues mentioned above under "Why not use `root`?" ### Completion criteria checklist

Patrick · November 7, 2024, 5:48am

upgrade-nonroot is broken at time of writing when qubes-core-agent-passwordless-root is not installed. But this, I’d like to fix soon.

File /etc/sudoers.d/upgrade-passwordless:

%sudo ALL=NOPASSWD: /usr/bin/apt-get-update-plus dist-upgrade

This means currently only members of group sudo can run upgrade-nonroot to perform passwordless operating system upgrades.

When package qubes-core-agent-passwordless-root is not installed, then user user is no longer a member of group sudo. Hence, this breaks.

To fix this, to be able to perform passwordless operating system upgrades as user user, one solution is to allow group members of group user [1] need to be allowed to run sudo upgrade-nonroot.

%user ALL=NOPASSWD: /usr/bin/upgrade-nonroot
%sudo ALL=NOPASSWD: /usr/bin/upgrade-nonroot

%user ALL=NOPASSWD: /usr/bin/apt-get-update-plus dist-upgrade
%sudo ALL=NOPASSWD: /usr/bin/apt-get-update-plus dist-upgrade

Note, changing this from group (or user) user to group (or user) admin as part of Multiple Boot Modes for Better Security: an Implementation of Untrusted Root would be future work. But for that, finding consensus first on create user `admin` by default and add user `admin` to group `sudo` by default · Issue #9519 · QubesOS/qubes-issues · GitHub would be most helpful. Otherwise the implementation for non-Qubes versus Qubes would differ, which would be a confusing usability issue.

[1] By default, only user user is a member of group user, this is inherited from Debian UserPrivateGroups.

nurmagoz · November 7, 2024, 8:43pm

Default or luxury? if default then dont fix, not the purpose. user need to use dom0 then use root to do root works inside Appvm/Template.

No passwordless operating system upgrades as a user user (doesnt matter fixed for admin to replace that or not currently, implementation is no root given to user).

Doesnt matter, let it be.

arraybolt3 · November 8, 2024, 1:40am

This is probably a bit of a twist on things, but personally I’d recommend omitting upgrade-nonroot entirely from the Qubes VMs. The reason for this is because upgrading qubes without using Qubes Update or application of Salt states is strongly recommended against for security reasons. Updates with Qubes Update should be doable without root even when qubes-core-agent-passwordless-root is absent (though I need to test this to be sure), but even if that doesn’t work, upgrade-nonroot should still be avoided on Qubes OS.

Patrick · November 8, 2024, 9:53am

In theory, that’s correct. In practice, Qubes documentation is written as if Qubes Update tool did not have critical issues. In other words, Qubes Update tool does have critical issues.

Quote Update Qubes-Whonix, Warnings:

The situation is however complicated due to Qubes Updater Issues , most notably such as:

qubes-dom0-update shows No updates available in case of network is down / qubes-dom0-update fails to notice if repositories are unreachable / network is down ,

Replace built-in Qube Manager update functionality with the Qubes Update tool .

This might need some updates with some more up-to-date examples.

As for quote:

is not recommended, since these bypass built-in Qubes OS update security measures

“sudo apt dist-upgrade → you’re compromised” obviously doesn’t happen.

Was discussed here: Announcement: Updating via direct commands no longer recommended by andrewdavidwong · Pull Request #79 · QubesOS/qubes-posts · GitHub

It would be rather involved to find out the current state of things (going through the Qubes Update tool bug list) but in any case, manual update commands inside a Template aren’t the end of the world, unless there’s a technical rationale why that would be the case.

Default.

Using Qubes Update tool also results in “some actions that require root” (such as running “sudo apt dist-upgrade”). Passwordless upgrades. So passwordless upgrades aren’t a bad thing by definition.

Flatpak updates are also possible with a simple flatpak update [1] run as user.

Why not? That’s how it’s done by:

Qubes Update tool
Android / iOS (most devices come with [non-root enforcement](Administrative Rights user freedom restriction by default), where users can update and install apps.
Probably any Linux distribution going “all-in” on flatpak / snap.
Probably any immutable and maybe verified boot supported Linux distribution. For many use cases, immutable + no root + no updates / app installation possible at all does not satisfy user requirements.

Depends on definition of “no root is given to user”.

On Android (according to https://www.youtube.com/watch?v=EkL1sDMXRVk, if I remember right), there is not even a root user or anything running as root user. Yet, the user is capable to perform actions which traditionally were reserved for root, such as apps installations, updating apps, configuring network (WiFi), power and battery management (users can control app battery usage, enable battery saver modes, and monitor power consumption without root), VPN configuration, airplane mode, accessibility settings, parental controls…

For example, WiFi configuration app on Android has only minimal permissions to change settings related to WiFi only. It doesn’t have real root rights. Similarly, sdwdate on Kicksecure or Whonix doesn’t run as root. It runs under user sdwdate but with capability accessibility (among other restrictions seen in its systemd unit file).

On Linux desktop distributions it’s similar. Battery management, WiFi setup, accessibility, app installation and updates are often possible without root.

Therefore “no root is given to user” can still remain true even if upgrade-nonroot exists.

Even user admin in non-Qubes (and even root in Qubes) could appreciate upgrade-nonroot as it combines “sudo apt update && sudo apt full-upgrade”.

The boundary root / non-root is getting more and more blurry. It’s more about permissions, designing who can do what and how (for example, based on Linux capabilities system).

It will also complicate the source code and documentation. Will require a lot “if non-Qubes, this; if Qubes, that”.

[1] In Qubes:

http_proxy=http://127.0.0.1:8082 https_proxy=http://127.0.0.1:8082 flatpak update

nurmagoz · November 12, 2024, 12:08am

Its not about passwordless vs password (yes), its about is there a capability to have a root access from the user when opening the terminal yes or not? yes bad, no good. simple

Out of scope for this discussion.

Debian is not Android nor IOS, because they are immutable OSs while kicksecure/debian are not.

If we were immutable that would the desired case but sadly we are not, so what we can achieve is to no ability to perform any actions which only privileged user/s can do like installing,removing,upgrading…etc unless he logged-in (non-qubes) or if in qubes case used dom0 terminal to enter root (or any username with privileges) to perform root/admin actions.

Thats the only way to reach as close as possible to the immutable security.

Its not, thats why they are separated, but it depends on the OS design, what each really mean and capable to do or if at all needed to be available to begin with. (same as above immutable VS mutable).

Out of scope for this discussion.

Patrick · November 12, 2024, 8:23am

I didn’t suggest to add the capability to have root access from user user terminal.

The purpose of this ticket is the opposite.

It seems root access isn’t well defined yet. Root access won’t be possible from user user by default. This includes (non-exhaustive list):

sudo su
su
lxsudo xfce4-terminal

upgrade-nonroot under my definition doesn’t grant root access to user user.

Flatpak itself is out-of-scope but examples on how to describe the root / user boundaries are in-scope. The question is, how does flatpak implement that? Answer: pkexec. File:
/usr/share/polkit-1/actions/org.freedesktop.Flatpak.policy

upgarde-nonroot can be implemented whether immutable or not. (Implementation details are different but from user perspective there is no big difference.)

For this discussion to make sense, it is required to have a basic understanding of the following two folders:

/etc/sudoers.d
/usr/share/polkit-1/actions/

These show, that the boundary between root / non-root is already “blurry”.

For instance, take /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy.

cat /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy | grep '<description>'

    <description>Enable or disable system networking</description>
    <description>Reload NetworkManager configuration</description>
    <description>Put NetworkManager to sleep or wake it up (should only be used by system power management)</description>
    <description>Enable or disable Wi-Fi devices</description>
    <description>Enable or disable mobile broadband devices</description>
    <description>Enable or disable WiMAX mobile broadband devices</description>
    <description>Allow control of network connections</description>
    <description>Allow control of Wi-Fi scans</description>
    <description>Connection sharing via a protected Wi-Fi network</description>
    <description>Connection sharing via an open Wi-Fi network</description>
    <description>Modify personal network connections</description>
    <description>Modify network connections for all users</description>
    <description>Modify persistent system hostname</description>
    <description>Modify persistent global DNS configuration</description>
    <description>Perform a checkpoint or rollback of interfaces configuration</description>
    <description>Enable or disable device statistics</description>
    <description>Enable or disable connectivity checking</description>

These are all actions which traditionally would have required the user to login as root or have full sudo access to edit arbitrary files and run arbitrary commands.

Nowadays the user can perform these actions “without requiring root or sudo”.

But what does “without requiring root or sudo” mean? It means the user does not need to use root/sudo. However, from the kernel / file system’s perspective, this is still a privileged action that requires “root” access.

So how does it work? Because the process is moderated by a helper utility. In this case, pkexec.

The pkexec configuration files in folder /usr/share/polkit-1/actions/ have file extension .policy. And that makes sense, because these files define the policy.

Similarly, /etc/sudoers, /etc/sudoers.d, /etc/doas.conf define policy.

What I am doing here is discussing the policy.

Should user user be allowed to restart sdwdate? (sdwdate-gui → VM name → restart sdwdate)
- Currently: allowed using /etc/sudoers.d snippet.

Should user user be allowed to view sdwdate logs using sdwdate-log-viewer? (sdwdate-gui → VM name → Open sdwdate’s log)
- Currently: allowed using /etc/sudoers.d snippet.
  - ```
  user ALL=NOPASSWD: /usr/bin/sdwdate-log-viewer
```
- Let’s suppose the answer is “no”. Then sdwdate-gui would need to run as user admin (or root). But that isn’t possible (or useful) because Qubes runs only 1 X server under user user. So saying “no” here would effectively mean to deprecate the functionality.

Should the user user be allowed to configure Tor using anon-connection-wizard / tor-control-panel?
- Currently: allowed using pkexec policy.
  - /usr/share/polkit-1/actions/com.kicksecure.anon-connection-wizard.policy
- Whonix-Gateway only.
- Let’s suppose the answer is “no”. Then anon-connection-wizard / tor-control-panel would need to run as user admin (or root). But that isn’t possible (or useful) because Qubes runs only 1 X server under user user. So saying “no” here would effectively mean to deprecate the functionality.

Should the user user be allowed to acquire administrative (“root”) rights using sudo su or similar?
- Currently: allowed by default because package qubes-core-agent-passwordless-root is installed by default.
- Planned: A purpose of this ticket is to no longer install qubes-core-agent-passwordless-root by default.

Should user user be allowed to acquire administrative (“root”) rights using sudo su or similar?
- Currently: Allowed by default because package qubes-core-agent-passwordless-root is installed by default.
- Planned: A purpose of this ticket is to no longer install qubes-core-agent-passwordless-root by default.

Should user user be allowed to run systemcheck?
- Currently: Allowed using /etc/sudoers.d snippet.
- Let’s suppose the answer is “no”. Maybe it should be “no”. But without Qubes supporting user admin it will not be possible to run systemcheck anymore. Could systemcheck be run as root? Might be possible but would actually be less secure.

Should the user user be allowed to update flatpak packages using flatpak update?
- Currently: Allowed by flatpak default’s pkexec policy.
  - /usr/share/polkit-1/actions/org.freedesktop.Flatpak.policy
- Let’s suppose the answer is “no”. We might need config-package-dev hide that policy file. Or even more drastic measures… [1] Then this would require some investigation. Flatpak would need to run system-wide as root. Or under user admin. If that is even possible. It might even turn out, that running flatpak as user instead of root is more secure.

Should the user user be allowed to run sudo apt-get upgrade && sudo apt-get dist-upgrade?
- Currently: Allowed due to qubes-core-agent-passwordless-root (and upgrade- nonroot, which is just a wrapper to combine the two commands).
- Planned: Makes sense to keep upgrade-noonroot.

[1] A system without any sudo at all. And/or a system without pkexec. Both provide functionality, but also have attack surface. This might require separate tickets.

I hope the point of the blurry boundary between user and root was made. /etc/sudoers.d and pkexec (policykit) are blurring that boundary. When considering user/root hardening, these have to be considered.

sudoers.d and pkexec enable controlled privilege escalation, allowing non-root users to perform specific actions safely, balancing usability with security. Overly restrictive systems risk users resorting to unsafe workarounds, so by providing access to essential functions without full root access, sudoers.d and pkexec support a secure, usable system.

By providing upgrade-nonroot, users are encouraged to upgrade more easily and more often. I don’t see anything insecure about upgrade-nonroot compared to already existing sudoers.d and pkexec exceptions (implemented by upstream projects, Debian, Qubes or Kicksecure).

In scope for this discussion, because Qubes sudo / su / root hardening needs answers for above questions. It cannot really be hardened without these considerations.