NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

UIPermission

The UIPermission defines access to various aspects of the Windows user interface: use of display windows, access to events, and use of the clipboard.

The window use level controls access to the window graphic user interface programming model, specifically: use of top-level windows, drawing in windows on the screen, handling user input and other events within the windowing system.

Partially trusted code may only use a special kind of window known as a “safe window” that guarantees the window will be appropriately labeled so that the user is aware of the source of the content, in order to prevent malicious use of such windows as mock system dialogs that might attempt to fool the user into entering a system password or some other kind of Trojan Horse attack.

The window use level of permission is represented as levels, listed from least to most restrictive:

  1. AllWindows: all windows & all events may be used
  2. SafeTopLevelWindows: safe top-level window use only – details follow
  3. SafeSubwindows: Only allow safe subwindow use (for embedded components)
  4. NoWindows: No window use allowed at all

Window use level of “safe” top-level window (2 above) allows use (including destruction) of any “safe” top-level window created within the app domain, and implies subwindow use (3). The friendly name of the app domain is used to reliably identify the code using the window to prevent impersonation of system messages and login requests by partially trusted content. Application has access to all events in these “safe” windows with exception of events in the title bar itself: the system menu and close button events cannot be intercepted. The specifics of the “safe” restrictions are as follows:

Window level use 3 allows drawing and event access is limited to one or more clipping subwindows associated with the app domain. This permission level is useful for embedded applications such as a control on a web page. The host (IE in this case) associates subwindows it wants to allow code to use within an app domain; the host must have unrestricted window permission granted. In doing so the host is responsible for enforcing the “safe” restrictions on the unrestricted top-level window the subwindow is on. In effect this allows a trusted host to make a “safe” subwindow within an unrestricted top-level window such that it behaves as a “safe” window for purposes of security.

For sub-PC devices with small displays (too small to support a windowed interface) window restrictions apply in a different yet analogous way as follows.

  1. AllWindows: entire screen & all events may be used
  2. SafeTopLevelWindows: N/A
  3. SafeSubwindows: Only allow drawing to a prescribed portion of the screen (under host control)
  4. NoWindows: No drawing is allowed at all

The clipboard access permission has three states:

  1. AllClipboard: any clipboard access is allowed
  2. OwnClipboard: paste from same app domain only (pending implementation cost)
  3. NoClipboard: no clipboard access is allowed

The middle permission level restricts clipboard paste operations to only work on content copied from the same app domain; the other states are self-explanatory. When the clipboard data is written on a copy operation, security information uniquely identifying the app domain of origin is recorded and subsequently compared at paste time to control access. Even unrestricted clipboard permission code should attach app domain context information on copy (could suppress this, but no clear reason why). Interoperability with IE would be desirable, but if cost is high is not required.

Drag/drop is always an intentional user interface operation, so there is no attack accessing private information (as long as windows are properly marked per the UIPermission) – no permission restriction. However, the API should be sure to only expose private information on the actual drop itself and not merely by dragging content over a window area (which could result in unintentional leak of data). The window event message queue restrictions need to prevent programmable simulation of drag & drop.