Harden Qubes by only allowing AppVM apps to get root privileges after UI-isolated user confirmation

[qubesuser]

Currently in Qubes any application running in Linux AppVMs can get root privileges by running su or sudo.

This means that it is possible to fully compromise the system with just 2 exploits: an application exploit and a Xen or Qubes RPC exploit.

If root privileges were not available, since most Xen exploits require ring 0 domU access, then either a much less likely to exist Xen exploit usable from ring 3 is needed, or 3 exploits are needed: an application exploit, a Linux kernel or privilege escalation exploit, and a Xen or Qubes RPC exploit.

This should make it significantly less likely that any given attacker is simultaneously in possession of all the non-public exploits needed and is willing to risk exposing them.

The standard Linux approach to this is to require a password, but this is a poor choice because it is easily circumvented by installing an X11 user-level keylogger that triggers on for "sudo\s.\n(.)" in the keystream and uses the recovered password to escalate.

Instead, the easiest approach for Qubes would be to have a custom PAM module that requests permission by asking dom0 to show a dialog box.

The best approach would instead be to have support to run multiple qubes-guid+Xorg+gui-agent stacks for each domain, and run 2 by default: one for the user and one for root, and change decorations to include the user after the vm name if it's not the default user.

Once that is done, the PAM module can just popup a normal X11 dialog using the root-only X server, which would require no special dom0 code and is still isolated.

The user experience would be very similar to Windows UAC prompts.

This way it would also be possible to run X11 applications as root in a way that is isolated from user application in the same domain.

It would also be possible to run several user accounts or "containers" with isolated X11 support in the same domain, which would be inferior to VM isolation, but could be useful if using VM isolation would require more RAM or more startup time than available.

The disadvantage is that it would be slightly less convenient to use in exchange for something that is merely hardening, but since escalating to root should be rare in everyday usage, it should still be worth it.

There should be an easy way to turn this off on a per-VM basis if the user desires.

[qubesuser]

An alternative or supplementary way of achieving this goal could be to make it impossible to execute arbitrary kernel code in AppVMs even with root privileges, by only allowing to load signed modules, disabling /dev/mem and /dev/kmem and in general turning on all the optional restrictions that have been added or proposed for the Linux kernel to support Secure Boot with a Microsoft signature.

However, this reduces functionality and it's not clear that all such holes have been removed, since Linux was not originally designed for this threat model.

It does add further mitigation compared to just preventing root since it means that an exploit that allows to gain root privileges but is not a Linux kernel exploit might not be enough to allow to use a Xen exploit and fully compromise the system.

[qubesuser]

An alternative or supplementary way of achieving this goal could be to make it impossible to execute arbitrary kernel code in AppVMs even with root privileges, by only allowing to load signed modules, disabling /dev/mem and /dev/kmem and in general turning on all the optional restrictions that have been added or proposed for the Linux kernel to support Secure Boot with a Microsoft signature.

However, this reduces functionality and it's not clear that all such holes have been removed, since Linux was not originally designed for this threat model.

It does add further mitigation compared to just preventing root since it means that an exploit that allows to gain root privileges but is not a Linux kernel exploit might not be enough to allow to use a Xen exploit and fully compromise the system.

[unman]

You've read this?
https://www.qubes-os.org/doc/VMSudo/

[unman]

You've read this?
https://www.qubes-os.org/doc/VMSudo/

[marmarek]

As described in the above page, we don't see this as feature we want by default. Anyway if someone want to configure it this way, he/she is free to do that.

[marmarek]

As described in the above page, we don't see this as feature we want by default. Anyway if someone want to configure it this way, he/she is free to do that.