Qubes sudo / su / root Hardening - Development Discussion

Qubes-Whonix
,
41
1 Like
42
1 Like
43

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.

1 Like
44

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.

1 Like
45

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.

1 Like
46

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 complicatedarchive.org due to Qubes Updater Issuesarchive.org, most notably such as:

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
1 Like
47

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.

1 Like
48

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.

1 Like
49

In the replace sudo with doas discussion I read that users will be instructed to open a root terminal, this page was linked to: Safely Use Root Commands

I want to add a reminder that it may be possible for Whonix to create a Dom0 desktop entry for a root terminal. It would make for a better user experience.

3 Likes
50

That would be good to have. This would be a Qubes dom0 feature. Unspecific to Whonix. A feature request against Qubes is needed.

1 Like
51

Starting from Whonix 17.3.0.5 and above…

Basic information:

Whonix-Workstation:

  • qubes-core-agent-passwordless-root: No. Will be no longer installed by default in new images.
  • user-sysmaint-split: Yes. Will be installed by default in new images.

Whonix-Gateway:

  • qubes-core-agent-passwordless-root: Yes, will remain installed by default in new images.
  • user-sysmaint-split: No, will not be installed by default.

See also:

2 Likes
52

To avoid getting package qubes-core-agent-passwordless-root accidentally uninstalled during sudo apt autoremove:

1 Like
53

Doesn’t make sense to me.

  • AppVM will be the one in use most of the time, changes to the root filesystem won’t persist giving no usability benefit
  • Vulnerabilities in software (sdwdate, tinyproxy, other services) will be able to freely connect over the clearnet, see your issue here

Passwordless root in templates is more acceptable. (I’m guessing services don’t start there?)

In that case you have a simple solution: test -f /run/qubes/this-is-templatevm && enable-passwordless-root

Qubes-Whonix should not have less leak proofness than non-Qubes-Whonix. Even if the Tor connection can be eavesdropped on, it’s a harder attack to pull off than to curl a unique checkpoint.

1 Like
54

Short versus long term usage is irrelevant in this specific threat model.

Actually, quite a bit is persistent. See folder: /usr/lib/qubes-bind-dirs.d/

That ticket generally makes sense for defense-in-depth. However…

No. I guess you’re referring to this sentence:

In the Qubes case of using sys-whonix for hosting the tinyproxy, compromise of the Gateway means compromise of the user identity.

That’s a bit terse indeed. But the issue tracker is a tool for developers. It’s not a comprehensive threat model description. A compromised sdwdate, tinyproxy cannot connect to clearnet. There are additional security boundaries. These daemons run under dedicated Linux user accounts. The firewall restricts these accounts to be able to connect to localhost (Tor) only.

An additional SUID exploit against a privilege escalation tool (such as sudo) or kernel exploit would be required to accomplish clearnet access.

It’s not elaborated on the Qubes issue tracker for brevity as the decision makers (Qubes team) know this.

services do start in Template unfortunately. Qubes issue:

This is inherited by an unfortunate default by Debian.

sysmaint-boot.target results in starting a minimal amount of services in non-Qubes but this won’t work in Qubes yet. We might be able to use sysmaint-boot.target, where only minimal services are run, in Template, but that’s not clear yet. We might open a Qubes ticket / implement this.

We’ve already developed the passwordless-root command line utility (requires root rights to run, of course), but this isn’t as trivial.

The issue is that passwordless-root makes persistent changes, which would later be inherited by App Qubes. So anything passwordless-root does, would need to be undone at Template shutdown. But a systemd unit that runs at shutdown can be unreliable due in in theory software bugs (in the systemd unit or script). Well, these can be gotten under control. But if there is a power loss, the Template would shutdown without reverting the passwordless root changes.

Allowing account user passwordless root in Template could be implemented using non-persistent overlays or perhaps better using PAM.

Right, but user-sysmaint-split isn’t required for that.

Please elaborate if still applicable.

Quoting myself:

An additional SUID exploit against a privilege escalation tool (such as sudo) or

This could be improved by making privilege escalation tools accessible only by account user.

user-sysmaint-split/usr/lib/permission-hardener.d/20_user-sysmaint-split.conf at master ¡ Kicksecure/user-sysmaint-split ¡ GitHub currently sets:

/usr/bin/sudo 4750 root sysmaint

This accomplishes No Access to Privilege Escalation Tools for Limited Accounts.

On Whonix-Gateway, a simpler implementation could be:

/usr/bin/sudo 4750 root user

1 Like
55
1 Like
56

Okay I see. I had not actually investigated how the sudoers rule works, my mistake. Those users do not have passwordless root due to not being in the qubes group, correct?

Therefore they cannot simply sudo -u clearnet (assuming they could execute any command).

Perhaps not so simple then, unfortunate. Fingers crossed that your propsal for a qrexec based solution is implemented on Qubes side some day.

With that cleared up my final concern is this: Does Whonix Gateway leak enough information to user user that it could reveal the users real IP address without the adversary having capabilities of a nation-state (i.e. power to subpoena or do traffic correlation)?

  • If yes, then I have no concern with passwordless root.

  • If no, then passwordless root makes it less leak proof.

I can’t think of a way to find the real IP without root even in sys-whonix, but it might very well be possible.

Personally running commands (especially as root) in Whonix Gateway is so rare for me that even a 1% security increase in this already unlikely scenario sounds beneficial. But I can only speak for myself.

1 Like
57

They’re neither a non-member (not a member of): sudo, wheel, qubes

I am not look forward to a qrexec based solution. Not sure how qrexec would help.

Considering now:

A PAM module that runs early, checks for file /run/qubes/this-is-templatevm existence, and results in pam_permit.so.

A Tor Controller such as nyx can access Tor control protocol feature GETINFO address.

But how is account user supposed to get compromised in the first place?

Quote user-sysmaint-split - Whonix-Workstation versus Whonix-Gateway - Default Installation Status Differences:

This is because, according to the threat model and usage instructions, the user should not use Whonix-Gateway for anything other than running and configuring Tor. End-user applications, such as a browser, should be run inside Whonix-Workstation. Therefore, according to our current understanding, user-sysmaint-split would have no security benefit for Whonix-Gateway. As a result, Whonix-Gateway will remain sudo passwordless by default for better usability. Whonix-Workstation will come with user-sysmaint-split installed by default. [1]

Added a footnote just now:

No user applications are running there, besides:

There’s no relevant attack surface. On Whonix-Gateway, the user isn’t running web browsers, which are more likely to get compromised. Therefore account user is “less” likely to get compromised.

What does “less likely” mean? In theory, a Tor controller parsing Tor control protocol output might get compromised if it’s somehow possible for an attacker to specifically craft messages so Tor control protocol outputs messages which exploit a Tor controller.

“Less likely” means, in this threat model, no realistic scenario under which account user is likely to get compromised has been identified yet. Unknown unknown and whatnot. But this is the point where we made a “shortcut” to:

  • pro usability,
  • only reasonably secure instead of maximum secure,
  • conservancy of development effort better spent on higher attack surface and priority issues.

That might be the case because above mentioned applications are pre-configured for passwordless sudo.

If user-sysmaint-split was installed by default on Whonix-Gateway, then using these applications would require

  • Non-Qubes-Whonix: to boot into sysmaint mode
  • Qubes-Whonix: Unclear. Figuring how to run GUI applications under account root or otherwise perhaps.

Or some other unknown implementation to keep these applications passwordless.

Why not require a password? If that was securely possible, we wouldn’t have implemented user-sysmaint-split. Issue sudo password sniffing is unsolveable. Known reasonably secure options starting these applications are only:

  • A) passwordless; or
  • B) booting into sysmaint mode (at time of writing for Non-Qubes only); or
  • C) considering the Template trusted and configuration inside Template (at time of writing for Qubes only)
1 Like
58

The ticket “Automate vm sudo authorization setup” suggests a dom0 prompt based on qrexec and PAM. Having that integrated into Qubes generally, and configurable via Qubes Global Config would be nice and allows for @type:TemplateVM allow, etc.

These are the types of leaks I was referring to with “does Whonix Gateway leak enough information for an adversary to find the real IP without subpoenas / traffic correlation”.

To compare with another anonymity distribution: Tails which does not use the split-VM architecture manages to hide the users real IP relatively well despite having sudoless access to Tor circuits, therefore the same should be a reachable goal in Whonix.

I agree that there is no tangible attack surface in Whonix Gateway when it is running as is, but users do not always run it “as is”. I have personally talked someone out of attempting to install a VPN in Whonix Gateway.

It is best not to assume that a user won’t shoot themselves in the foot, try to install software, run dangerous commands, and in the case that they do restricting root could still prevent deanonymization (as is done in Tails).

What I am advocating for at this point is that it is preferable that a user gets stuck, seeks help on the wiki or forum and is educated rather than to do something potentially dangerous which could compromise their anonymity.

As I mentioned before, there are very few situations you would run root commands in sys-whonix (AppVM), therefore I would imagine misuse by non-technical people is higher than legitimate use. (Some people prefix every command with sudo…)

1 Like
59

This won’t work due to No Access to Privilege Escalation Tools for Limited Accounts. We could probably only use overlays / bind mounts for that.

How to make it configurable, qrexec or qvm-service is more of a detail that is easily figured out later. qrexec / qvm-service isn’t the answer to solve the main problem to implement this.

The main challenge for now to implement (passwordless or password protected) sudo in Qubes Template is to deal with No Access to Privilege Escalation Tools for Limited Accounts versus Template persistence and App Qube inheritance.

Protecting the user from oneself is outside the scope of this ticket. There’s a separate topic for that:
walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode

Tor circuits is also a sensitive information. Hence, not accessible by Whonix-Workstation by design.

In Tails such a restriction is useful because it’s not a split-VM design.

1 Like
60

I’m not sure I view it like that. Reading that ticket, it sounds like a large scale effort to e.g. run all applications under a separate user or with sandboxing. Limiting root in the Whonix Gateway AppVM sounds more like a sensible default.

The attack surface is primarily the user, correct, but it’s not a “preventing the user from doing anything harmful” thing, rather a “if you do mess up, your IP isn’t immediately leaked” thing. My comparison with Tails still holds up: If you can do it in Tails without leaking your IP, it should be possible in Whonix Gateway.

I won’t pursue this further, I hope I got my point across though.

Will there be upgrade instructions or is installing a new template necessary?

1 Like