Qubes vm-sudo documentation write-up against sudo passwords inside App Qubes outdated

[adrelanos]

https://www.qubes-os.org/doc/vm-sudo/ is outdated.

The comment

# WTF?! Have you lost your mind?!
#
# In Qubes VMs there is no point in isolating the root account from
# the user account.

This is evidenced by file /etc/sudoers.d/qubes which previously had this comment, having nowadays this comment removed. That write-up was just a copy of /etc/sudoers.d/qubes.

Already in 2017, Joanna upgraded her viewpoint, see:
#2695 (comment)

This ticket is still open, which means Qubes would be open if the community would implement this.

[adrelanos]

See also discussion in QubesOS/qubes-doc#1365

It's hard for me to guess @marmarek's opinion on this. It might be easier to just update. Discussion might require more time than updating it.

# WTF?! Have you lost your mind?!
#

Rewrite for more professional language.

Also no need to use all code tags for the write-up. I am approaching this from a viewpoint how such a write-up would look nowadays if written from scratch with the knowledge we have nowadays.

# In Qubes VMs there is no point in isolating the root account from
# the user account.

Rewrite because sudo hardening makes sense. By sudo hardening I mean having VMs that by user discipline on purpose never get root / never run commands with sudo / su. This makes sense for example for VMs supposed to be only used by lets say a web browser or e-mail client.

Was revised as per #2695 (comment) as it apparently is harder to break out of a VM without root / kernel level access.

Could be rewritten to "Root account isolation, VMs that never have access to root are more secure because this might prevent some cases of VM escape vulnerabilities."

This is because all the user data is already
# accessible from the user account, so there is no direct benefit for
# the attacker if she could escalate to root (there is even no benefit
# in trying to install some persistent rootkits, as the VM's root
# filesystem modifications are lost upon each start of a VM).

Need to keep mentioning that an attacker having compromised user but not root is in many cases already considered catastrophic by the user. For example, if a VM to run gpg that holds the private keys compromised, then the keys are gone. Root access by the malware would not make that worse unless the malware uses this for the purpose of VM escape to compromise other VMs too.

However in other cases such as low priority youtube watching VM, malware trapped as user without root access would be a security benefit.

# One might argue that some hypothetical attacks against the
# hypervisor or the few daemons/backends in Dom0 (so VM escape
# attacks) most likely would require root access in the VM to trigger
# the attack.

Delete because this opinion was revised as far as I understand.

# That's true, but mere existence of such a bug in the hypervisor or
# Dom0 that could be exploited by a malicious VM, no matter whether
# requiring user, root, or even kernel access in the VM, would be
# FATAL. In such situation (if there was such a bug in Xen) there
# really is no comforting that: "oh, but the mitigating factor was
# that the attacker needed root in VM!" We're not M$, and we're not
# gonna BS our users that there are mitigating factors in that case,
# and for sure, root/user isolation is not a mitigating factor.

Delete because a multi-layered security approach where user volunteer non-root enforcement for some VMs is being used is sensible.

# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- as of 2016, there have been only three publicly disclosed
# exploitable bugs in the Xen hypervisor from a VM

Delete because outdated. It's best to just delete wrong/outdated information. And the burden to update these numbers should not be on the contributors deleting outdated information. If someone thinks the number of Xen bugs is relevant, this could be re-added later.

-- then it would be
# highly unlikely if that person couldn't also found a user-to-root
# escalation in VM (which as we know from history of UNIX/Linux
# happens all the time).

Not sure if outdated, still true or speculation. In doubt, delete. Just keep true, concise, relevant statements.

# At the same time allowing for easy user-to-root escalation in a VM
# is simply convenient for users, especially for update installation.

True.

# Currently this still doesn't work as expected, because some idotic
# piece of software called PolKit uses own set of policies. We're

Delete because this issue has been resolved.

# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
# simple experiment: start 'xinput test' in one xterm, running as
# user, then open some app that uses PolKit and asks for root
# password, e.g.  gpk-update-viewer -- observe how all the keystrokes
# with root password you enter into the "secure" PolKit dialog box can
# be seen by the xinput program...)

Delete because this issue has been resolved in Wayland? And Qubes not using Wayland yet is a bug (or missing feature) in Qubes. Also not relevant for VMs that never use sudo by user set policy.

#
# joanna.

Delete because Joanna isn't here to defend, update this viewpoint anymore and might have revised it meanwhile anyhow. (#2695 (comment))

[andrewdavidwong]

Related issue: #7237

[emanruse]

Considering this forum thread, I would like to mention a few things for consideration here:

In regards to the particular "WTF document":

Strictly speaking, it is a quote of a code comment. Code documentation and user documentation are different things, having different qualities, different purpose and different classes of readers. As it is now, it does not seem to qualify for either.

It is hyperbolic, includes cynicism and does not provide an actual in-depth explanation of the security logic (as discussed in the forum thread and as many failed to understand). It kind of says that as long as Xen is protected, nothing else matters, including the user data in the AppVM. While that has certain validity, it cannot be the essence, as data is the central reason of computing. If the logic is that we must be ready to dump data just to avoid a "security theater", we can as well stop using computers (because of Intel ME, etc.) What I mean is that the implication that the AppVM is either perfectly clean or must be dumped as a whole, implies also that security is either 0 or 100%, which is impossible.

So, this document needs to clarify from user data viewpoint:

• How exactly passwordless root helps to protect user data better (aligning with the security focus as a goal of Qubes OS)

• How exactly having restricted root will make it worse (i.e. how qvm-run -u root VM <command> in dom0 is worse than sudo command in domU)

Then, one can understand for oneself what to do, not merely be told "you are free to do what you like" without knowing why and without understanding the consequences.

User documentation should not be there just because of its author (who we all surely respect) and should not be a holy scripture not to be questioned by anyone. So far, as it seems, all threads trying to discuss it result in meaningless repetition of pro- and anti- positions without much healthy reasoning. However, even the author herself seems willing to change the current default in the issue that @adrelanos linked to. IIUC, it is just not clear how to do it properly. Even that seems disregarded by most of the proponents.

Also, the popular mantra that the documentation is a "community effort" does not apply to code comments. So, this must be documented properly, not just placed as a sensationalist statement.

[adrelanos]

@unman in QubesOS/qubes-doc#1365 (comment)

This PR is based on a mistaken view - that the original page contains "highly outdated, since revised viewpoints"

In #2695 (comment) Joanna said:

I've been recently talking about this with Solar Designer of Openwall (a person who probably knows more about Linux security model than most of us together), and below I try to summarize the outcomes of our discussion:

1. The primary reason to even consider any kind of root account isolation within Qubes AppVMs is to make it more difficult for attackers to launch attacks against Xen (most, or perhaps all of the XSAs that affected Qubes required root in the VM).

2. This "protect Xen" goal is significantly more important that any kind of in-VM isolation, e.g. ability to run different apps as different user accounts. Indeed, current Xorg doesn't make this feasible architecturally even, and in fact it's been one of the Qubes fundamental goals to fix this (long before anybody started even talking about Wayland that apparently also tries to fix this).

This is something where I would guess that @marmarek also agrees.

If so, then this revises the currently stated viewpoint in Qubes documentation:

# In Qubes VMs there is no point in isolating the root account from
# the user account.

Hence I used the words "highly outdated, since revised viewpoints".

Makes sense?

[ben-grande]

@adrelanos

# In Qubes VMs there is no point in isolating the root account from
# the user account.

Rewrite because sudo hardening makes sense. By sudo hardening I mean having VMs that by user discipline on purpose never get root / never run commands with sudo / su. This makes sense for example for VMs supposed to be only used by lets say a web browser or e-mail client.

Already possible via the sudo authotization via Qrexec, that does not invalidate the document and you have to opt-in. It is not the default because Qubes Team does not agree it increases security.

---

Was revised as per #2695 (comment) as it apparently is harder to break out of a VM without root / kernel level access.

It was not revised in that comment, it is more "steps to accomplish" such thing. It still stands that with current authorization mechanism, privilege escalation is still possible

Marmarek said:

Well, all those points about isolation (or rather lack of it) a user with shell/arbitrary exec access from root (if the user can actually get root access, via some extra authorization) are still very much true. If you can use sudo with some extra steps, then malicious code on your user account can simply wait until you perform those extra steps, whatever they are.

So, most of this description is still accurate. The thing that changed is we made the password-less root access opt-out, if you have a case where you more or less never use sudo at all. In fact, uninstalling passwordless-root package prevents using sudo for arbitrary commands at all (unless you configure some alternative authorization).

---

Could be rewritten to "Root account isolation, VMs that never have access to root are more secure because this might prevent some cases of VM escape vulnerabilities."

We've seen that privilege escalation vulnerabilities to root account is quite frequent while VM escape is less frequent. From what I understood, if one can escape the VM, they can escape the normal user account and putting this barrier just make it more difficult to use Qubes for normal users that won't just do browsing and e-mail client, but will want to install a single package in the template and won't understand that they need to use qvm-console-dispvm (and login as root) or qvm-run -u root to be able to get the package installed.

---

This is because all the user data is already
# accessible from the user account, so there is no direct benefit for
# the attacker if she could escalate to root (there is even no benefit
# in trying to install some persistent rootkits, as the VM's root
# filesystem modifications are lost upon each start of a VM).

Need to keep mentioning that an attacker having compromised user but not root is in many cases already considered catastrophic by the user. For example, if a VM to run gpg that holds the private keys compromised, then the keys are gone. Root access by the malware would not make that worse unless the malware uses this for the purpose of VM escape to compromise other VMs too.

However in other cases such as low priority youtube watching VM, malware trapped as user without root access would be a security benefit.

Not a security benefit in Qubes architecture as of today, again linking to Marmarek response:

If you can use sudo with some extra steps, then malicious code on your user account can simply wait until you perform those extra steps, whatever they are

---

# One might argue that some hypothetical attacks against the
# hypervisor or the few daemons/backends in Dom0 (so VM escape
# attacks) most likely would require root access in the VM to trigger
# the attack.

Delete because this opinion was revised as far as I understand.

Please point out where.

Joanna comment:

1. The primary reason to even consider any kind of root account isolation within Qubes AppVMs is to make it more difficult for attackers to launch attacks against Xen (most, or perhaps all of the XSAs that affected Qubes required root in the VM).

Marmarek's comment to your PR

If you can use sudo with some extra steps, then malicious code on your user account can simply wait until you perform those extra steps, whatever they are

---

# That's true, but mere existence of such a bug in the hypervisor or
# Dom0 that could be exploited by a malicious VM, no matter whether
# requiring user, root, or even kernel access in the VM, would be
# FATAL. In such situation (if there was such a bug in Xen) there
# really is no comforting that: "oh, but the mitigating factor was
# that the attacker needed root in VM!" We're not M$, and we're not
# gonna BS our users that there are mitigating factors in that case,
# and for sure, root/user isolation is not a mitigating factor.

Delete because a multi-layered security approach where user volunteer non-root enforcement for some VMs is being used is sensible.

Can you please rephrase your argument, I did not understand it.

---

# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- as of 2016, there have been only three publicly disclosed
# exploitable bugs in the Xen hypervisor from a VM

Delete because outdated. It's best to just delete wrong/outdated information. And the burden to update these numbers should not be on the contributors deleting outdated information. If someone thinks the number of Xen bugs is relevant, this could be re-added later.

Agreed, easy to get outdated.

---

-- then it would be
# highly unlikely if that person couldn't also found a user-to-root
# escalation in VM (which as we know from history of UNIX/Linux
# happens all the time).

Not sure if outdated, still true or speculation. In doubt, delete. Just keep true, concise, relevant statements.

Not outdated, not especulation and not doubt.

Privilege escalation vulnerability published 2024-01-30, less than a month ago, affecting Fedora

For example, we confirmed that Debian 12 and 13, Ubuntu 23.04 and 23.10,
and Fedora 37 to 39 are vulnerable to this buffer overflow. Furthermore,
we successfully exploited an up-to-date, default installation of Fedora
38 (on amd64): a Local Privilege Escalation, from any unprivileged user
to full root. Other distributions are probably also exploitable.

It is still true, concise and relevant.

---

# Currently this still doesn't work as expected, because some idotic
# piece of software called PolKit uses own set of policies. We're

Delete because this issue has been resolved.

# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
# simple experiment: start 'xinput test' in one xterm, running as
# user, then open some app that uses PolKit and asks for root
# password, e.g.  gpk-update-viewer -- observe how all the keystrokes
# with root password you enter into the "secure" PolKit dialog box can
# be seen by the xinput program...)

Delete because this issue has been resolved in Wayland? And Qubes not using Wayland yet is a bug (or missing feature) in Qubes. Also not relevant for VMs that never use sudo by user set policy.

Do not remove because Qubes is not using Wayland. When Qubes starts using it, this point can be revised.

The comment about "not relevant for VMs that never use sudo by user set policy" is not true, Flatpak for example, still uses pkexec.

#
# joanna.

Delete because Joanna isn't here to defend, update this viewpoint anymore and might have revised it meanwhile anyhow. (#2695 (comment))

It was written in mail format, it is her signature, gives credibility to the author and I don't see this stopping this discussion happening with any other Qubes developer or community, as it is just happening in this issue and many others.