VISTA中的变化

无语啊无语。这变化让程序结构都要变化了。

Vista Challenge I (session isolation)
We spend about 4 months on R&D and final got it working with some support of the MS helpdesk.

Vnc and all remote control softwares are having trouble withy the new Vista security model. In de old model, winlogon was always running in the same session as the services, session0



While in the new model, the winlogon run in the same session as the desktop.



The isolation of the session0, now only used for services, prevent winvnc in service mode to access session X and no interaction with the desktop in session X is possible. Using the service, you can't logon or capture the desktop.

Running winvnc in application mode ( started manual in sessionX) all seems to work as long as you don't logoff or use any system application that popup the UAC.

Solution I
Winvnc need to split exe in a service and a application part. When we run the winvnc_service in session0 and let the service start winvnc_app in the sessionX, winvnc_app can communicate with the desktop and control the mouse and keyboard.

An other problem is that sessionX have different desktop, let's take a closer look how desktop exist in Vista. (This model was already partly in use on XP, for the "Fast user switching", remember the black screen you had with VNC after switching user)

- Session 0

|  |

|   ---- WinSta0 (interactive window station)

|  |   |

|   |  ---- Default (desktop)

|  |   |

|   |   ---- Disconnect (desktop)

|  |   |

|   |   ---- Winlogon (desktop)

|   |

|   ---- winvnc Service (non-interactive window station)

|   |   |

|   |   ---- Default (desktop)

|   |

- Session 1

|  |

|   ---- WinSta0 (interactive window station)

|   |   |

|   |   ---- Default (desktop)(1**)

|   |   |

|   |   ---- Disconnect (desktop)

|   |   |

|   |   ---- Winlogon (desktop)

|   |

- Session 2

| |

| ---- WinSta0 (interactive window station)

| | |

| | ---- Default (desktop)

|

| | ---- Disconnect (desktop)

| |   |

| | ---- Winlogon (desktop)  (2**)

The service need to check the console desktop and session.
If the console desktop is (1**) the service need to start winvnc_app in session1 on the default desktop, the default desktop is the normal desktop where your application run on.
If the console desktop is (2**) the service need to start winvnc_app in session2 on the winlogon desktop, this is the secure desktop used to logon.
To avoid access problems, you best start the winvnc_app with the same security context as the desktop he is started in.
Default Desktop --> user
Winlogon Desktop -> local system
Createprocessasuser() allow the service to start the exe in the correct security context.

This method would be a complete solution to support Fast user switching and access on PC's running RDP. But Vista has other nasty tricks to prevent applications to control a desktop.

Vista Challenge II (elevation and UAC)
Security elevation
From previous MS OS's you know that permissions where based on users. If you logged on as administrator, you could simple click on an executable to start it. As normal user, you needed execute permission on that executable.
In Vista applications have a "security elevation".
Low: Iexplorere started as administrator runs in low security elevation, this block iexplorer access to many system sources and applications.
Normal: A standard application, word pad, run in normal elevation.
High: For system utilities, like service manager..
The elevation block some interaction from lower elevated application to higher. For Vnc the most important is that sendinput() is blocked. You can't control an application running in higher elevation then the elevation winvnc is running.
If you start the service manager from within VNC, VNC mouse clicks get locked by the elevated "service manager" application.
If the remote users minimize the "service manager" you have full access again, but remote you are blocked.

UAC
In older OS version you could simple start a "system application" with a double click, in Vista the UAC jumps in. The UAC popup a "OK" window in the secure desktop, he temporal switch to the winlogon desktop and ask your permission to execute that program.
The problem for VNC is that your winvnc_app running in the default desktop has no permission to access the winlogon desktop, remote the whole desktop lock and you need to ask the remote user the press the ok button to continue.

Solution II
UAC problem can be solved by restarting the winvnc_app in the winlogon desktop, to press OK, and the restarting it again in the default desktop.
Great, but now VNC lock because the "system app" has focus and sendinput() is locked because it run in "high" elevation.
No problem, should you think, we just add a manifest to the winvnc_app and tell that it need to start in "high" elevation, then it can control all application. ( elevation high has access to all elevation >=high)
This works, when you manual click on the winvnc_app.exe, it popup the UAC and you press OK, but when you start it from the service you get a permission denied, CreateprocessAsUser(CPAU) is not allowed to start elevated application......

Don't play with the manifest, the only way is to play with the token passed to CPAU and pass the full elevated token, then winvnc_app start elevated and you have access.

Vista Challenge II ( Ctrl-alt-del)
In previous OS's you could send a message from a service in the winlogon desktop to simulate the CAD sequence...
PostMessage(HWND_BROADCAST,WM_HOTKEY,0,MAKELPARAM(MOD_ALT|MOD_CONTROL,VK_DELETE));
This does not work in Vista....

Solution III
We are testing, it has to be possible, the osk (on screen keyboard) can simulate the sequence. The osk use undocumented functions, the "winlogon IPC API"...
As workaround, you can use the on screen keyboard. When you press the left/down icon it popup the keyboard and you can that to simulate CAD...
Problem solved , Ctrl-Alt-Del can be made with a separate exe "cad.exe"