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

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: https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132

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

See also discussion in https://github.com/QubesOS/qubes-doc/pull/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 https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132 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. (https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132)

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.

@unman in https://github.com/QubesOS/qubes-doc/pull/1365#issuecomment-1951495683

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

In https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132 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:

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

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?

@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:

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.

Considering

usability is a goal
restricted root can still be beneficial (otherwise Joanna would not consider it)

is it not possible to have restricted root ON by default in domUs and confirm root access through a dialog box (like we allow e.g. inter-VM file copy)? If that is possible, then probably it can also be controlled via policy in dom0?

@emanruse Right now, various devices under /dev/xen are accessible by any user in the qubes group. This is needed for unprivileged processes to use vchans, but likely allows escalation from the qubes group to root.

There are a couple of alternatives:

Do nothing.
Have every vchan-using program be set-user-id root. I’m not sure if this is a reasonable approach, especially because I don’t know if the Xen libraries are safe to use in setuid programs.
Use a privileged daemon for all vchan and grant operations.
Move the libvchan implementation into a kernel module. I very much like this approach, but it it is quite a bit more work.

The security of non-root enforcement generally

It's futile to argue that non-root enforcement cannot improve the security of the system (in case of Qubes, of an App Qube).

Non-root enforcement is the industry standard for Android [1], iOS and any locked down Linux based operating system.

Status of Qubes Documentation

The Qubes documentation currently summarized states: "There is no security benefit from non-root enforcement." This is outdated. Also https://github.com/QubesOS/qubes-issues/issues/2695 still being open contradicts this.
More up-to-date would be: "Non-root enforcement would provide better security, getting there is difficult and requires more Qubes development."

Xorg issues?

I am not sure how Xorg in the absence of a vulnerability helps with escalation to root.
Xorg runs as non-root in Qubes.
Xorg is a counter-argument is vanishing. One day Qubes must be ported to Wayland because Xorg has been abandoned upstream, distributions are moving away from it and at some point Qubes won't be able to use it any longer.
But Qubes is still using Xorg nowadays? Ok, but one day it won't so no reason to claim that non-root enforcement would not improve security.

/dev/xen issues

Ok, but solvable in theory. That does not speak against non-root enforcement being a security advantage. It only means that further Qubes development work would be required until users can (fully) benefit from non-root enforcement.

Usability issues?

That's a different thing. There is A) security and B) usability. These are related but different. These should not be mixed. In theory it might be the case that A), non-root improvement improves security but it cannot or should not be implemented because that would be infeasible usability wise. I don't think that is true either but I want to focus on the security argument.

An Implementation of non-root Enforcement in Qubes

Users just need to know their YouTube-Firefox App Qube should never be grated root rights.

A solution with good usability and user freedom would be if the user could opt-in "non-root enforcement" in Qubes dom0 App Qube settings using QVMM (Qubes VM Manager). Once enabled, it would be impossible for such VMs to gain root access.

(Unless the user would undo this setting in dom0, which could be secured by a proper warning. Or you could even "fuse" the setting if you must.)

But how about application installation, which requires root? That would still be done in Template. Elaborated in the next chapter.

But Android is Different...?

[1] But Android is different because app installation is possible without root rights? Yes, but Qubes could accomplish something similar.

Template: always has root access by default.
App Qube: user can opt-in to enable non-root enforcement.

In result this would mean for example for a YouTube-Firefox App Qube:

application installation: Inside Qubes Template using root.
application execution: Inside App Qube with opt-in non-root enforcement.

The would be more secure. Then Qubes would be closer to some of the security features which are standard in other operating systems such as Android.

But in Android the application can be shared with multiple user accounts? Yes. And in Qubes it could be shared with multiple App Qubes.

Really could be quite a similar design.

User forgotten sudo/root password usability issue

Not an issue in my design proposal: In the design which I suggested, there is no need for any sudo/root passwords as root access vs non-root enforcement would be controlled through Qubes dom0 setting on a per App Qube basis.
But an issue for other designs: It would even be possible to allow users to set a root password using dom0 QVMM settings. Not a design that I would find useful. But that goes far off-topic into implementation details which can be discussed later once basis consensus on "non-root enforcement improves security, let's accept it as project goal, patches welcome".
Not an issue for dom0 prompt based designs: Because if the sudo prompt happens in dom0 - which is a different design from what I suggested here - then also no password will be required.

Answers

@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,

I think this is a more complex design, less secure, harder to develop compared to the strictly non-root enforcement Qubes dom0 setting for App Qubes.

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.

This I am not sure about.

[2] Qubes dom0 controlled non-root enforcement setting (as described above) + xorg fix (Wayland) + /dev/xen issues fix + any other required fixes = security benefit from non-root enforcement? @marmarek

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

All I want is the Qubes documentation to acknolwedge what I think the fact is: non-root enforcement if done right (with all the auxiliary required fixes) would improve the security. It's okay to admit that future development is required, the feature being rejected even but at least should be factually correct, see above [2].

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.

This (if the user can actually get root access, via some extra authorization) is the critical "if", the remaining security hole, which my design proposal here closes.

The malicious code would need to wait forever because it would never happen. I am sure there are many (power) users who would understand that their browser, e-mail App Qube using software from repository package sources has no reason to request root ever.

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.

None of these complicated commands are required. Template could always have root access. App Qube could have a non-root enforcement setting in dom0.

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

Not as if today but could be a benefit in the future if the auxiliary issues get resolved.

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.

We can actually keep that sentence 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.

Joanna comment:

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

No extra steps possible in my proposal here.

# 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.

Security can be multi-layered.

browser hardening
kernel hardening
non-root enforcement
Qubes App Qube isolation

The user could volunteer, speak opt-in, to enable non-root enforcement for some App Qubes.

There's no need to argue against multi-layered security concepts. Just because there is Qubes App Qube isolation, doesn't mean other security features should be neglected.

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

Ok, nvm that part.

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.

Then it can be amended to mention the future, Wayland.

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

An initial implementation of the non-root enforcement design which I suggested here could be implemented while fully disabling pkexec. Not a blocker. Pkexec support could be considered, improved later once basic consensus has been reached.

#
# 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.

Once anything from a quote was modified (except for minor formatting), then it should be no longer claimed the author said exactly that. At most it could be said "this write-up was based on [source] by [author] and modified for this website" to stay truthful.

Credibility is established by being on the Qubes website. In other places on the Qubes website there's neither specific authorship recognition. I am suggesting for the Qubes website to update, improve the statement.

QubesOS / qubes-issues

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