Qubes sudo / su / root Hardening - Development Discussion

[Patrick]

@Patrick

Considering now:

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

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.

@qwhnx

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.

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.

@qwhnx

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

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

@qwhnx

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.

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.