GUI/Admin domain splitting

[marmarek]

Reported by joanna on 27 Apr 2014 12:32 UTC

• Allow to "kiosk" the GUI domain reasonably for corporate applications
• Allow to use "whatever" OS as GUI domain (e.g. Windows) -- we just need gui-daemon ported to that OS
• Potentially requires "qubesd" (discussed elsewhere)
• Requires vm-to-vm vchan for GUI protocol

Migrated-From: https://wiki.qubes-os.org/ticket/833

[rootkovska]

ITSTM we can attempt to create the first version of GUI domain without the need to have a GPU passthorugh working (which itself is a complex topic). This is the sketch of the idea (for Qubes 4.x):

1. Designate one of the AppVMs as "GuiDom". Allow GuiDom to run as full screen.
2. Run only a very minimal window manager in Dom0. In theory only to display the GuiDom window, in practice we might want it to be able to handle some hot keys and open a terminal window (e.g. when Qubes booted in "debug" or "admin" mode). Do not provide trusted decorations.
3. Run one of the normal Qubes-aware window managers in GuiDom, e.g. Xfce4 with Qubes customization.
4. Run gui-daemons (guids) in the GuiDom, and have other VMs connect to these GuiDom's guids.
5. Each guid running in GuiDom behave a bit like a proxy, in that it also plays a role of a gui-agent from the perspective of Dom0. Specifically, it does not attempt to display the composition buffer as received from its corresponding agent (MSG_MFNDUMP), but forwards this to the Dom0 guid.
6. However, in order for the local window manager running in GuiDom to be able to normally manage windows (apply trusted decorations, control focus, etc), it does draw (to the dummy GuiDom's X server) windows and decorations in response to MSG_CREATE, MSG_CONFIGURE, etc. It's just that the contents of these windows is never to be displayed on the GuiDom dummy X server, only by the actual guid in Dom0. This way we save on unnecessary memcpy's, preserving the zero-copy property of the whole protocol.

Pros:

1. Ability to lock down the user. I.e. the user has no full admin access (no full access to Dom0), only a limited access as allowed by our management policy (which is coming in Qubes 4.0). This is considered a required functionality for any business/corporate deployment of Qubes OS,
2. Isolation of the whole Desktop Environment software stack from Dom0,
3. Provides a smooth way to switch to "true GuiDom" (i.e. one with full GPU pass-through) in the future.

Cons:

1. No GPU acceleration for the (effective) window manager, e.g. no nice eye candy effects. But we already don't have much of these in Xfce4... (but maybe shadows will be no longer?)
2. No isolation of (potentially compromised) GPU device (but we don't have that now anyway).

The #1 will be a regression from the present state (GuiDom = Dom0). It will be fixed by switching to a true GuiDom later. Meanwhile we can offer this feature as an opt-in during installation.

Of course this all requires ability to run e.g. Qubes Manager and qvm-tools in GuiDom and have control over what these management tools can and cannot do. And this is exactly what our shiny new exciting Qubes API Management will allow in 4.0 :)

[rootkovska]

ITSTM we can attempt to create the first version of GUI domain without the need to have a GPU passthorugh working (which itself is a complex topic). This is the sketch of the idea (for Qubes 4.x):

1. Designate one of the AppVMs as "GuiDom". Allow GuiDom to run as full screen.
2. Run only a very minimal window manager in Dom0. In theory only to display the GuiDom window, in practice we might want it to be able to handle some hot keys and open a terminal window (e.g. when Qubes booted in "debug" or "admin" mode). Do not provide trusted decorations.
3. Run one of the normal Qubes-aware window managers in GuiDom, e.g. Xfce4 with Qubes customization.
4. Run gui-daemons (guids) in the GuiDom, and have other VMs connect to these GuiDom's guids.
5. Each guid running in GuiDom behave a bit like a proxy, in that it also plays a role of a gui-agent from the perspective of Dom0. Specifically, it does not attempt to display the composition buffer as received from its corresponding agent (MSG_MFNDUMP), but forwards this to the Dom0 guid.
6. However, in order for the local window manager running in GuiDom to be able to normally manage windows (apply trusted decorations, control focus, etc), it does draw (to the dummy GuiDom's X server) windows and decorations in response to MSG_CREATE, MSG_CONFIGURE, etc. It's just that the contents of these windows is never to be displayed on the GuiDom dummy X server, only by the actual guid in Dom0. This way we save on unnecessary memcpy's, preserving the zero-copy property of the whole protocol.

Pros:

1. Ability to lock down the user. I.e. the user has no full admin access (no full access to Dom0), only a limited access as allowed by our management policy (which is coming in Qubes 4.0). This is considered a required functionality for any business/corporate deployment of Qubes OS,
2. Isolation of the whole Desktop Environment software stack from Dom0,
3. Provides a smooth way to switch to "true GuiDom" (i.e. one with full GPU pass-through) in the future.

Cons:

1. No GPU acceleration for the (effective) window manager, e.g. no nice eye candy effects. But we already don't have much of these in Xfce4... (but maybe shadows will be no longer?)
2. No isolation of (potentially compromised) GPU device (but we don't have that now anyway).

The #1 will be a regression from the present state (GuiDom = Dom0). It will be fixed by switching to a true GuiDom later. Meanwhile we can offer this feature as an opt-in during installation.

Of course this all requires ability to run e.g. Qubes Manager and qvm-tools in GuiDom and have control over what these management tools can and cannot do. And this is exactly what our shiny new exciting Qubes API Management will allow in 4.0 :)

[marmarek]

However, in order for the local window manager running in GuiDom to be able to normally manage windows (apply trusted decorations, control focus, etc), it does draw (to the dummy GuiDom's X server) windows and decorations in response to MSG_CREATE, MSG_CONFIGURE, etc. It's just that the contents of these windows is never to be displayed on the GuiDom dummy X server, only by the actual guid in Dom0. This way we save on unnecessary memcpy's, preserving the zero-copy property of the whole protocol.

I think it will be at least tricky to get this part right. First, you'll need to embed one shm-mapped image (actual window content) into another another one (window with decorations). And then you'll need to synchronize all the window positions (including above/behind relations) and focus across three VMs. We already have problems while doing it with two VMs: #2311 #1455
So, this part may be harder than it seems. Not sure if harder than proper GPU passthrough - maybe yes (especially when considering only selected GPU support), maybe no.

[marmarek]

However, in order for the local window manager running in GuiDom to be able to normally manage windows (apply trusted decorations, control focus, etc), it does draw (to the dummy GuiDom's X server) windows and decorations in response to MSG_CREATE, MSG_CONFIGURE, etc. It's just that the contents of these windows is never to be displayed on the GuiDom dummy X server, only by the actual guid in Dom0. This way we save on unnecessary memcpy's, preserving the zero-copy property of the whole protocol.

I think it will be at least tricky to get this part right. First, you'll need to embed one shm-mapped image (actual window content) into another another one (window with decorations). And then you'll need to synchronize all the window positions (including above/behind relations) and focus across three VMs. We already have problems while doing it with two VMs: #2311 #1455
So, this part may be harder than it seems. Not sure if harder than proper GPU passthrough - maybe yes (especially when considering only selected GPU support), maybe no.

[rootkovska]

Another benefit of having a separate GUI domain is discussed in #2743.

Also a note: even though having a (semi-untrutsed) GUI domain would not prevent such hypothetical attacks coming from HDMI or DP ports, we at least gain ways to cleanup/revert the GUI domain back to the known good state. This will be discussed in an upcoming post I'm currently working on (which will cover IR more broadly on Qubes).

[rootkovska]

Another benefit of having a separate GUI domain is discussed in #2743.

Also a note: even though having a (semi-untrutsed) GUI domain would not prevent such hypothetical attacks coming from HDMI or DP ports, we at least gain ways to cleanup/revert the GUI domain back to the known good state. This will be discussed in an upcoming post I'm currently working on (which will cover IR more broadly on Qubes).

[v6ak]

Well, it might be some mitigation factor, but it depends on circumstances: * Qubes-unaware attacks might be mitigated this way. * If GUI domain is kept more up-to-date, it is more likely to contain fixes for publicly-known vulnerabilities. (Remember glibc vulnerability being unpatched in 3.0/3.1 for months because of assumption dom0 is never connected to network…) * Qubes-aware attacks with remote administration cannot take over dom0 this way (unless it is chained with some VM-escape vulnerability). But it could take over all AppVMs to the degree they can be taken-over by end user. * For Qubes-aware attacks with local administration, the GUI domain can IIUC take over dom0. Joanna Rutkowska wrote:

This will be discussed in an upcoming post I'm currently working on (which will cover IR more broadly on Qubes).

What do you mean by “IR” there? Nothing from “Interrupt remapping”, “Infra-red” and “Intermediate Representation” seems to fit thereby.

[v6ak]

Well, it might be some mitigation factor, but it depends on circumstances: * Qubes-unaware attacks might be mitigated this way. * If GUI domain is kept more up-to-date, it is more likely to contain fixes for publicly-known vulnerabilities. (Remember glibc vulnerability being unpatched in 3.0/3.1 for months because of assumption dom0 is never connected to network…) * Qubes-aware attacks with remote administration cannot take over dom0 this way (unless it is chained with some VM-escape vulnerability). But it could take over all AppVMs to the degree they can be taken-over by end user. * For Qubes-aware attacks with local administration, the GUI domain can IIUC take over dom0. Joanna Rutkowska wrote:

This will be discussed in an upcoming post I'm currently working on (which will cover IR more broadly on Qubes).

What do you mean by “IR” there? Nothing from “Interrupt remapping”, “Infra-red” and “Intermediate Representation” seems to fit thereby.

[tasket]

@v6ak I agree. We can use a euphemism like "semi-untrusted" for display/graphics, but its still an inherently trusted component meaning the security justification is shaky (also means MS Windows is unsuitable).

FWIW, the GPU firmware situation isn't so terrible when we have integrated GPUs to choose from.

I also agree with ITL's angle that a display VM makes the system more maintainable as dom0 undergoes radical transformation, but overall the benefit isn't nearly as great as implementing a storage VM or other features.

[tasket]

@v6ak I agree. We can use a euphemism like "semi-untrusted" for display/graphics, but its still an inherently trusted component meaning the security justification is shaky (also means MS Windows is unsuitable).

FWIW, the GPU firmware situation isn't so terrible when we have integrated GPUs to choose from.

I also agree with ITL's angle that a display VM makes the system more maintainable as dom0 undergoes radical transformation, but overall the benefit isn't nearly as great as implementing a storage VM or other features.

[v6ak]

also means MS Windows is unsuitable

Why? Trusting MS is matter of choice. I know it is closedsource etc., but if someone decides to trust them, what is wrong with using Windows as GUIVM? Also, I guess Windows is mentioned as an example (showing even theoretical options that are allowed by this change) rather than as way-to-go.

FWIW, the GPU firmware situation isn't so terrible when we have integrated GPUs to choose from.

Do you mean that iGPU's firmware cannot be usually reflashed? Maybe I am not getting your message here.

[v6ak]

also means MS Windows is unsuitable

Why? Trusting MS is matter of choice. I know it is closedsource etc., but if someone decides to trust them, what is wrong with using Windows as GUIVM? Also, I guess Windows is mentioned as an example (showing even theoretical options that are allowed by this change) rather than as way-to-go.

FWIW, the GPU firmware situation isn't so terrible when we have integrated GPUs to choose from.

Do you mean that iGPU's firmware cannot be usually reflashed? Maybe I am not getting your message here.

[jpouellet]

What do you mean by “IR” there? Nothing from “Interrupt remapping”, “Infra-red” and “Intermediate Representation” seems to fit thereby.

Based on recent interest in #2737, my guess is Incident Response.

Do you mean that iGPU's firmware cannot be usually reflashed? Maybe I am not getting your message here.

It is prohibitively expensive to fabricate fast CPUs and persistent storage in the same process, so the firmware must be loaded from somewhere off-chip. This presents an opportunity to verify said firmware, and ensures we have a reliable mechanism by which to reset it to a known-clean state. This is not the case with a discrete GPU with its own firmware storage which can be re-flashed and then leveraged for other low-level attacks, e.g. DMA in early boot or something.

[jpouellet]

What do you mean by “IR” there? Nothing from “Interrupt remapping”, “Infra-red” and “Intermediate Representation” seems to fit thereby.

Based on recent interest in #2737, my guess is Incident Response.

Do you mean that iGPU's firmware cannot be usually reflashed? Maybe I am not getting your message here.

It is prohibitively expensive to fabricate fast CPUs and persistent storage in the same process, so the firmware must be loaded from somewhere off-chip. This presents an opportunity to verify said firmware, and ensures we have a reliable mechanism by which to reset it to a known-clean state. This is not the case with a discrete GPU with its own firmware storage which can be re-flashed and then leveraged for other low-level attacks, e.g. DMA in early boot or something.