Bug 1860062 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I'm about to land this change, but before I do I just want to document how I arrived here, because I tried increasing the GPU sandbox past where it is in several ways, but all of them returned failures:

-   Job level: Currently at `JOB_LIMITED_USER`. Increasing one level to
    `JOB_RESTRICTED` prevented GPU process from accessing the `hWnd` of the
    compositor window. This was not fixed even if all UI restrictions were
    lifted.

    Interestingly, even getting rid of the few remaining UI exceptions (like
    the ability to shutdown windows) also broke things. It seems like Windows
    must disable some entire subsystem in an all-or-nothing fashion when all
    the required mitigations are enabled, and when we cross that line it
    breaks our GPU process.

-   Integrity Level: Currently at `INTEGRITY_LEVEL_LOW`. Increasing to
    `INTEGRITY_LEVEL_UNTRUSTED` caused `VRShMem` to stop initializing properly.

-   Delayed Integrity Level: Same as the initial Integrity Level

-   Access Token: Currently at `USER_RESTRICTED_SAME_ACCESS`. Increasing to
    `USER_NON_ADMIN` prevented GPU process from accessing the `hWnd` of the
    compositor window.

-   Delayed Access Token: Currently at `USER_RESTRICTED_NON_ADMIN`. Increasing
    to `USER_LIMITED` was successful in my testing.

-   I did not play around too much with the OS-level mitigations, as none of
    them struck me as something that would help above-and-beyond what we
    already had.

So, overall the only headway I was able to make for Sandbox Level 2 was an increase in the Delayed Access Token from `USER_RESTRICTED_NON_ADMIN` to `USER_LIMITED`. 

This is actually the same conclusion David Parks had reached when he worked on this years ago, so I guess it's nice to see two separate people arrive at the same conclusion 😎
I'm about to land this change, but before I do I just want to document how I arrived here, because I tried increasing the GPU sandbox past where it is in several ways, but all of them returned failures:

-   Job level: Currently at `JOB_LIMITED_USER`. Increasing one level to
    `JOB_RESTRICTED` prevented GPU process from accessing the `hWnd` of the
    compositor window. This was not fixed even if all UI restrictions were
    lifted.

    Interestingly, even getting rid of the few remaining UI exceptions (like
    the ability to shutdown windows) also broke things. It seems like Windows
    must disable some entire subsystem in an all-or-nothing fashion when all
    the required mitigations are enabled, and when we cross that line it
    breaks our GPU process.

-   Integrity Level: Currently at `INTEGRITY_LEVEL_LOW`. Increasing to
    `INTEGRITY_LEVEL_UNTRUSTED` caused `VRShMem` to stop initializing properly.

-   Delayed Integrity Level: Same as the initial Integrity Level.

-   Access Token: Currently at `USER_RESTRICTED_SAME_ACCESS`. Increasing to
    `USER_NON_ADMIN` prevented GPU process from accessing the `hWnd` of the
    compositor window.

-   Delayed Access Token: Currently at `USER_RESTRICTED_NON_ADMIN`. Increasing
    to `USER_LIMITED` was successful in my testing.

-   I did not play around too much with the OS-level mitigations, as none of
    them struck me as something that would help above-and-beyond what we
    already had.

So, overall the only headway I was able to make for Sandbox Level 2 was an increase in the Delayed Access Token from `USER_RESTRICTED_NON_ADMIN` to `USER_LIMITED`. 

This is actually the same conclusion David Parks had reached when he worked on this years ago, so I guess it's nice to see two separate people arrive at the same conclusion 😎.

Back to Bug 1860062 Comment 5