Security: Make password-less sudo work differently and configurable in Qubes Manager

[t4777sd]

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

Proposal

Change the way password-less sudo is implemented. Instead of the current method which is very heavy-handed it would be better to implement the "Dom User Prompt" method. Then, by default, each created VM can be added as an exception to the /etc/qubes-rpc/policy/qubes.VMAuth file. This maintains current behavior of password-less sudo with no prompting.

The advantage of this is that users can toggle password-less sudo and dom-prompt sudo just by commenting that file with no other major and involved mofications (which can brick a VM if done incorrectly as sudo becomes inaccessible).

And, ideally, they can select per-VM via an option in the Qubes Manager. That way, with a click of a chieckbox, they can turn on and off the sudo prompt

Why is it important to give users the option for Dom prompting?
One of the big security benefits of Qubes outside of the isolation provided by Xen is that once an AppVM restarts its system files revert to their previous state. So, if they are infected, the infection gets removed as a side-effect in most cases.

However, this is not true and users should be aware that it is not true. Any malware that can run code can modify the bind-dirs in /rw/. The only thing stopping them from this is the need for root access, which password-less sudo conveniently grants them root access in a very easy manner.

Cost of making this change and benefit received

The Dom prompt can help prevent a class of attacks. Considering the infrastructure for the Dom prompt is already completed it only takes very little effort to make the change to make it toggle-able and there is a non-insignificant security gain.

[andrewdavidwong]

Duplicate of #2748

[andrewdavidwong]

Duplicate of #2748

[andrewdavidwong]

This appears to be a duplicate of an existing issue. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[andrewdavidwong]

This appears to be a duplicate of an existing issue. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[t4777sd]

I do not believe this is a duplicate of #2748. Here is why:

1. 2478 describes many additional changes beyond merely changing sudo behavior. Sudo behavior is just one small part. What I propose is a simple and elegant solution without all the other cruft.

2. 2478 requires making sudo prompting otherwise the other changes discusssed have no use. My proposal gives people the option to make it prompting on a per-VM basis and make it toggle-able.

[t4777sd]

I do not believe this is a duplicate of #2748. Here is why:

1. 2478 describes many additional changes beyond merely changing sudo behavior. Sudo behavior is just one small part. What I propose is a simple and elegant solution without all the other cruft.

2. 2478 requires making sudo prompting otherwise the other changes discusssed have no use. My proposal gives people the option to make it prompting on a per-VM basis and make it toggle-able.

[marmarek]

I think it's rather duplicate of #2695

Anyway, please note that disabling password-less root access is not only about sudo (see https://www.qubes-os.org/doc/vm-sudo/). Other points (like PolicyKit) do not have such easy and elegant equivalent.

[marmarek]

I think it's rather duplicate of #2695

Anyway, please note that disabling password-less root access is not only about sudo (see https://www.qubes-os.org/doc/vm-sudo/). Other points (like PolicyKit) do not have such easy and elegant equivalent.

[t4777sd]

@marmarek I am not that familiar with policykit honestly. Does the policykit changes allow an attacker to gain root privledges due to the changes in policykit even if sudo prompt is enabled?

[t4777sd]

@marmarek I am not that familiar with policykit honestly. Does the policykit changes allow an attacker to gain root privledges due to the changes in policykit even if sudo prompt is enabled?

[marmarek]

If you follow above linked page (or remove/not install qubes-core-agent-passwordless-root package), then no. Part of instruction is reverting PolicyKit config.
But by default we ship a configuration allowing anyone execute "admin" commands through PolicyKit, as part of qubes-core-agent-passwordless-root package. This in practice is equivalent to root access.

[marmarek]

If you follow above linked page (or remove/not install qubes-core-agent-passwordless-root package), then no. Part of instruction is reverting PolicyKit config.
But by default we ship a configuration allowing anyone execute "admin" commands through PolicyKit, as part of qubes-core-agent-passwordless-root package. This in practice is equivalent to root access.