New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support UI Automation within a Windows Defender Application Guard process #7600
Conversation
changes: * UIAHandler.getNearestWindowHandle: If this UIAElement's processID is for a local WDAG container process, jump up to its root (UIA className of "ApplicationFrameWindow") and use that element's windowHandle. Any windowHandle from UIAElements below this root are not valid on this machine. However before we check for the WDAG process, if the processID of the original element is 0, search up for the first valid one (Known WDAG bug) * UIAHandler.IsNativeUIAElement: If the processID is 0 (such as with UIAElements currently in WDAG), treat this UIAElement as having a native UIA implementation * UIA NVDAObject: don't get the processID of the UIAElement, instead fallback to getting it off its window. Currently a UIAElement in WDAG may have a processID of 0. This is a known bug. It should be the processID of the local container process.
…ag container process, then this element should be classed as being native. * Ensure IUIAutomationElement.cachedNativeWindowHandle is never used when it is not local -- needs to be rethought a bit.
…this allows screen hittesting, and allows us to remove some other code from UIAHandler.isNativeUIAElement.
Hi,
For anyone commenting on this pull request, WDAG was announced in 2016, and introduced in Version 1709 (Fall Creators Update). Thus, tests should be done by other Windows Insiders running Windows 10 Enterprise or Education Version 1709 Preview. Thanks.
|
CC @derekriemer who uses Windows 10 Education, functionally equivalent to Windows 10 Enterprise.
Edit: Removed quoted email.
|
It is also worth noting that several major UI Automation bugs in WDAG
were fixed and are only available as of build 16288. In fact running
WDAG with or with out this code on prior builds may cause hangs or crashes.
|
Is there some way that NVDA can query for the name of the WDAG process? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for me to re-review the review actions, unless you think the changes require it.
source/_UIAHandler.py
Outdated
appModule=appModuleHandler.getAppModuleFromProcessID(processID) | ||
# WDAG (Windows Defender application Guard) UIA elements should be treated as being from a remote machine, and therefore their window handles are completely invalid on this machine. | ||
# Therefore, jump all the way up to the root of the WDAG process and use that window handle as it is local to this machine. | ||
if appModule.appName==u'hvsirdpclient': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be handy to pull the process name out and store it in a class or module level constant. The name might be handy when someone searches for WDAG_PROCESS_NAME
or similar
We can query the name of (a given) process. A WDAG process will have a
name of "hvsirdpclient".
There is no other way I know of to identify a process as a WDAG process
apart from checking the name.
Simply, I believe this UI Automation implementation is flawed as the
nativeWindowHandle property does not expose a valid windowHandle as the
spec promises.
|
…r in WDAG by also looking for File Explorer's UIA class name.
Summary of the issue:
On Windows 10 Enterprise, it is now possible to run Microsoft Edge within Windows Defender application Guard (WDAG). WDAG is a stripped-back version of Windows running in a special virtual machine that can securely isolate a process from the rest of the system.
The only way that an asistive technology can talk to the isolated process is via UI Automation. Nothing else can cross the machine boundary.
WDAG perfectly forwards the UI Automation implementation from the isolated process, but changes the processID property on each UIA element to expose the local WDAG process ID rather than the process ID inside the VM. However, the following two problems exist:
These problems together mean that NVDA pretty much stays silent when focus is within a WDAG process and therefore if a user decides to run Microsoft Edge in this fassion it is completely inaccessible.
Description of how this pull request fixes the issue:
These changes make NVDA function with Microsoft Edge in WDAG exactly the same way it would if Edge was running locally. The only difference being a noticeable drop in responsiveness.
Testing performed:
On a windows 10 Enterprise machine:
Known issues with pull request:
If the name of the WDAG process ever changes (it is currently hvsirdpclient), not only will the WDAG process be inaccessible, but most importantly NVDA and or other parts of the system may experience hans or crashes due to the use of a nativeWindowHandle from a remote machine that is not valid locally. I have suggested to Microsoft that this is a major risk. Note though that without this PR the risk still remains the same.
Change log entry:
New features: