Session 0 Isolation and Secure Desktop: Windows 7 AppCompat Series


In Windows XP and earlier versions of the Windows OS, all services run in the same session as the first user who logs on to the console. This session is called Session 0. Running services and user applications together in Session 0 poses a security risk because services run at elevated privilege and therefore are targets for malicious agents who are looking for a means to elevate their own privilege level.

In Windows 7, the OS creates Session 0 for Services and User Mode Drivers, and creates Session 1 for first user logging in. Running services and user applications in two different Sessions avoid the security risk, because services cannot run at elevated privilege and therefore stops malicious agents. Now when we have a legacy application, in which the application which is running in Session 1 invokes a system service and waits for the user’s interaction, UI displayed by this service is not visible as it is running in a secure desktop. Interaction between Session 0 and Session 1 does not happen. Hence an application, which has a Service and user application communicate using window message functions or local objects fail to execute.

sessions

How OS Responds

If the application’s service uses a UI, a built-in mitigation in Windows 7 allows the user to interact with the Session 0 UI in a special desktop. This will make available the UI specific to the application, instead of the entire Session 0 desktop. For example – : When we try to convert any document to pdf using the application which uses this mechanism, it throws the Session 0 isolation error message. On Clicking, Show me the message, it takes the user to a secure desktop, where only the dialog/service which is prompting for the user’s interaction will be showed.

session0

Also check out this presentation on Session 0 Isolation – Windows 7

Few developer guidelines involve

  1. Redesigning the application and service to use client or server mechanisms, e.g. Remote procedure calls (RPC) or named pipes. Also, redesign the service to no longer interact directly with the user
  2. If the application creates globally named objects, then use the Windows XP compatibility mode to ensure that the application will continue to work with the Session 0 services.
  3. Test and verify the application on Windows XP in a Terminal Server mode or a Fast User Switching (FUS) mode. If the application works properly on Windows XP in these scenarios, then it is very likely to work under Windows 7.
  4. Apply “Session Shim” in the compatibility administrator for fixing these issues and Verify that the application functions properly after applying the Windows XP compatibility mode, which contains mitigation for some of the Session 0 issues.
  5. For other Developer Guidelines, Click here

For More Compatibility articles, Check here – http://www.msigeek.com/category/compatibility/

The Complete Application Compatibility Series