Policy evaluation problem
Brought to you by:
istvan_hoffmann,
valerypryamikov
Adding the built in confirmation dialogs changed the policy evaluation process also. Because of bad implementation the process skips the second pass of evaluation (where the annoying rules runs) if the request came from shell extension. Also can bother you with false 'Unrestricted startup' confirmation question anytime if the requested level less restricted than defined in the policy. The confirmation of less restricted run than defined in the policy does not happen if the requested level is not 'Unrestricted'
Revising the release we found the reported bug is a by design behavior.
Version beta9 and later does not evaluate (therefore not calling annoying rules) just check the policy if the privileged open signal came from the shell extension.
We handle 4 ways of file open
1. Open from external source (via shell execute hook and a signal to RunAsAdmin)
2. Open via our command dialog (directly by our explorer.exe using CreateProcess(AsUser)
3. Open using drag and drop onto our tray icon
4. Open via shell context menu (via shell context menu extension and a signal to RunAsAdmin)
1st Might happen from any program that might already run at any privilege level so in that case a full policy evaluation happens in signal handling, when the annoying rules are also processed.
2nd-4th now treated as a file open direct user request exactly on the user requested level and these events are not going through a full policy evaluation process (of course policy check happens, but no annoying rule processed)
In both cases a confirmation might be also required based on RunAsAdmin user settings.
We could redesign this in a feature release as the evaluation might happen in case of every file open. (which could lead a more annoying behavior perhaps)
Because only way 1 and 4 goes through signaling only that 2 CAN (now) lead to policy evaluation.
To make every kind of file open go through that process, to behave the same way, we have to add signaling to 2 and 3 instead of the direct call of internal CreateNewProcess.
This might require the current user policies modification.