Integrity Level and the ROT

Integrity Levels result in surprising behavior. The other day I was looking at an accessibility application. Since accessibility applications need to be able to access applications that are potentially running with a MIC level of high, there is a setting in the manifest specifically for this purpose called uiAccess=true. If your application has this setting it will get a filtered token and a high MIC level, where normally it would get a filtered token and a medium MIC level.

Enumerating the ROT from an admin application (high MIC unfiltered token) will give me this:

E:\Code\Roguer\Roguer.sln

!DExplore.AppObj.8.0:5820

!{BA018599-1DB3-44F9-83B4-461454C84BF8} ProgID: VisualStudio.DTE.8.0

!{1B2EEDD6-C203-4D04-BD59-78906E3E8AAB} ProgID: VisualStudio.Solution.8.0

!{639F725F-1B2D-4831-A9FD-874847682010} ProgID: DExplore.AppObj.8.0

!VisualStudio.DTE.8.0:2644

Running it from a standard user token (filtered token, medium MIC) will give me

!{000209FF-0000-0000-C000-000000000046} ProgID: Word.Application.12

Document6

Document4

!{0006F03A-0000-0000-C000-000000000046} ProgID: Outlook.Application.12

!{FB50E079-F904-4833-B7C0-309366351F3A}

C:\Program Files\Microsoft Office\Templates\1033\Blog.dotx

Document3

!{000209FE-0000-0000-C000-000000000046} ProgID: Word.Basic.9

The list is completely different. And running it from a uiAccess=true application will give me:

Correct. Nothing. ROT is partitioned by user token and then again by MIC level. No application has registered itself with a filtered token with high IL.

Consequence of this is that accessibility applications need to use an intermediate process with filtered-medium-MIC token to get access to Word or other applications that are registered in the ROT.

Maarten