forderud / runinsandbox Goto Github PK

Steps to reproduce:

• From a elevated command prompt: "C:\Dev\RunInSandbox\x64\Debug\TestControl.exe" -Embedding
• Observe that elevated "TestControl.exe" process is created.
• From a regular command prompt: x64\Debug\RunInSandbox.exe TestControl.TestControl
• Observe that a new non-elevated "TestControl.exe" process is created instead of connecting to the existing process.

Docs: https://learn.microsoft.com/en-us/windows/win32/com/the-com-elevation-moniker

Tested approaches

• HKEY_LOCAL_MACHINE\Software\Classes\AppID\{APPID}\ROTFlags = 0x01: Didn't help (need to switch to ROT to make it work)
• HKEY_LOCAL_MACHINE\Software\Classes\AppID\{APPID}\RunAs = "Interactive User": Did help 👍

.Net wpf-test problem report: DuplicateTokenEx ImpersonationLevel type mismatches

Solution: Add user or group to associated "log on as ..." security policy:

Steps to reproduce:

• Create a local MyAdmin account that is member of the "Administrators" group.
• Run ComRunAs.exe {264FBADA-8FEF-44B7-801E-B728A1749B5A} MyAdmin <pw>
• Run RunInSandbox.exe TestControl.TestControl.
• Observe ERROR: The server process could not be started because the configured identity is incorrect. Check the username and password.
• From Component Services configure "TestControl object" to run with MyAdmin as identity
• Run RunInSandbox.exe TestControl.TestControl.
• Observe that the COM server runs as expected

Token dumps from system with UAC disabled:

mi_token_from_uac.txt
mi_proc_from_elevated.txt
mi_proc_from_uac.txt
mi_token_from_elevated.txt

Findings

• No observable differences in either impersonation token or COM server token as listed by WinDbg.
• Disabling UAC does not help.

To investigate

A hint from me: plz add an OutputDebugString before SetCursorPos and log the GetForegroundWindow() to ensure the foreground window is the expected one. Why OutputDebugString? It calls the underlying DbgPrint in kernel level and has minimal impact to possible shift of windows focus. BTW it is my favorite debugging log func since Windows 95, where it was first publicly available.

Are the relevant UIPI rules documented somewhere, so that I can study them carefully? I’m especially interested in the precise definition of “foreground window” for nested window hierarchies spanning processes running at different integrity levels.

the foreground window is the window, which a) receives the user input at this moment and b) is processed by thread processing current input windows messages - aka foreground thread. Foreground window doesn't belong necessary to the currently running app (it isn't the active window of the app).
If Word activates an embedded Visio drawing for editing by user, the foreground window is not the word window but the visio.

WinDbg kernel debugging

• Attach to TestControl.exe
• Add ``...

Any tips on how I can get more detailed diagnostics on the failing SetCursorPos call? Is there a system log somewhere that reveal more clues about the precise reason for the failure?

yes, you can try kernel debugger int win32k.sys and set breakpoint to win32kfull!zzzSetCursorPos

ba0 e 1 win32kfull!zzzSetCursorPos "dx -r0 win32kbase!gpqForeground->uipiInfo->dwIntegrityLevel;dx ((win32kbase!THREADINFO*)(((win32kbase!W32THREADNONPAGED*)((nt!ETHREAD*)@$thread)->Tcb.Win32Thread)->pW32Thread))->ppi->uipiInfo->dwIntegrityLevel"

Links: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/getting-started-with-windbg--kernel-mode-

Hey, thanks for this project and helping me to get started with AppContainers. Few system apps work fine. I've been trying to containerize an electron app but almost all of them fail to launch in less than medium integrity level even with broad set of permissions.

Lets take Signal messenger as an example here. Can you please have a look and let me know if I'm missing some key minor aspects. It would be very helpful if I can get a demo electron app working inside the AppContainer.

.Net bug report: dotnet/runtime#96397

IMPACT: It's currently not possible to implement startup of apps in sandboxed processes due to this bug.

.Net runtime source seach

https://github.com/search?q=repo%3Adotnet%2Fruntime%20DuplicateTokenEx&type=code

Make a tool for configuring AppID RunAs credentials from the command-line. Use https://github.com/forderud/RunInSandbox/blob/master/RunInSandbox/RunAs.hpp as starting point.

Attempting to run "RunInSandbox.exe TestControl.TestControl <username> <password>" works fine when impersonating an admin user. However, it fails with with: hr = 0x80080005 : Server execution failed when attempting to impersonate a non-admin user.

The following event is also logged in the Windows System event log:

The server {F0DFBE77-1697-428E-A895-EFEE202B9333} did not register with DCOM within the required timeout.

Precondition:

Enable TestControl Object DCOM local "launch" and "activation" permissions for the impersonated user. Failure to do so will lead to CoCreateInstance failing with E_ACCESSDENIED.

This can also be enabled globally through the default DCOM launch & activation permissions:

Steps to reproduce

1. Build RunInSandbox & TestControl projects.
2. Create a new user account that is only member of the "Users" group.
3. Enable local DCOM "launch" and "activation" for the new user.
4. Verify that "RunInSandbox.exe TestControl.TestControl <username> <password>" fails with CO_E_SERVER_EXEC_FAILURE
5. Add user to "Administrators" group
6. Verify that "RunInSandbox.exe TestControl.TestControl <username> <password>" now succeed.

Revert effbe35 that uses LogonUser

Observed problem: SetCursorPos calls fail in a medium IL COM/OLE control when running as child window within an elevated (high IL) host process.

The reason for this failure seem to be that UIPI silently blocks SetForegroundWindow calls in the medium IL COM/OLE control after setting WS_CHILD window style and connecting it to the host window through SetParent. This happens despite the host having called CoAllowSetForegroundWindow first.

Steps to reproduce

• From a command prompt started with "Run as Admin": RunInSandbox.exe mi TestControl.TestControl
• Observe the following error:

Moving mouse cursor to top-left corner...
[FAILED] Access is denied.

This problem does not occur if running RunInSandbox.exe mi TestControl.TestControl from a non-elevated command prompt.

Code tweaks to make it work

Applying any one of the changes below will make the problem go away:
1, Stop setting the WS_CHILD window style.
2. Stop calling SetParent(child_wnd, wnd).
3. Run SetCursorPos from a non-main thread in the COM/OLE process (change the first MoveMouseCursor argument to true).

Tweak 1. and 2. does not seem attractive, since they would undermine the child window UI integration. Tweak 3. is furthermore not attractive, since it would require invasive changes to the COM/OLE control to make it "parent IL aware".

I'm therefore seeking a non-invasive way of "granting" the COM/OLE control permission to SetForegroundWindow or being allowed to send SetCursorPos events to the high IL parent window also after being attached as a child window.