| Scripting Around Session 0 Isolation |
 |
 |
|
Millions of administrators worldwide depend on the ability of a Windows Service to display a message on the user desktop for coordination of software distribution activities. Generally this involves communications such as allowing the user to defer software distribution jobs, notification that a distribution job is underway in the background or informing that a software installation is complete. The new security feature in Windows 7 known as “Session 0 Isolation” now blocks this communication from occurring. This CSI-Windows.com Toolkit addition presents a reasonable secure, simple method for getting around the Session 0 barrier. The ProblemQuick note: This script is part of our course Win7 LUA/Non-Admin Application Integration Engineer (ENG-60). Under Windows XP all services and the interactive user logon all reside in Session 0. This architecture is what allows services configured with “Allow this service to Interact with the Desktop” to display a user interface directly to end users. This design is also susceptible to attacks on privileged services from code started by the logged on user. Figure 1 shows session 0 isolation depicted as a sort of special security boundary. In reality it is just standard operating procedure that services that display a UI will display it in the default desktop for their session, which is no longer the same session as the user in Windows 7. Microsoft publishes several methods for allowing a service to establish a connection with the user desktop. The primary method involves designing a process that runs in the user session that can receive communication from service processes and present any necessary UI to the end user. The suggested communications mechanisms include RPC, Named Pipes, Terminal Server APIs (WTSSendMessage), mapped memory or the CreateProcessAsUser API. None of these methods are easily usable via scripting. This SolutionScripting is always about doing the most with the least. This solution leverages the registry as a communication mechanism between server and client processes. Since WMI allows efficient registry change notification, we can effectively design a client side process that monitors for messages from services and displays a UI in the user session and returns the response of the user via the registry as well. Using the registry also gives programming language neutrality – the service side can be written in any language. Using the registry also allows the most simplistic languages or other mechanisms to be used – where advanced programming such as RPC and calling Windows APIs requires more sophisticated programming tools. There are really two aspects to this solution: a) the architecture of using the registry and WMI monitoring – this could be done in most any language by following the same principles, b) a feature complete VBScript solution ready for deployment – this VBScript installs the registry keys and sets their permissions, monitors the queue, can be uninstalled, shutdown, restarted, reinstalled, logs to the event log, contains debugging code and cleans up the registry keys on startup. Multiple queues can be deployed simultaneously by simply renaming the .VBS. The architecture of passing messages back and forth between processes through an intermediary layer is known as “message queuing”. It is important not to confuse the architectural concept of “message queuing” in this solution with dedicated products and middleware that perform message queuing of database transactions. The basic concept is displayed in Figure 1. The message queue utilizes two registry keys - “Inbox” and “Outbox”. By default these keys are located in HKCU and the server process does some queries to find out which user registry hive has a queue processor running against it. The queue can also be run out of HKLM if necessary (for simplicity of qsender processes) - in this case the queue must be installed by an administator before a regular user can run the qmonitor against it. With a little redesign the registry keys could be made even more secure by making the service completely responsible for removing anything it has put into the inbox. There are several reasons why this is probably not necessary - first, the primary communication channel is from a privileged service to the less privileged user desktop, second, the queue monitor looks only for a specific named value, third, the queue monitor can only process contents intended to be displayed with the vbscript popup method, anything else wouldn't work. CSI-Windows.com-MsgQ.vbs is capable of being run as a service and receiving messages from the user session – this type of implementation is when more security precautions are needed.
MsgQ-Tester.vbs also contains sample code that may be useful on your server side script for the following items:
TRK-60 Win7 LUA/Non-Admin Application Integration EngineerThis script is covered in more detail in our training track TRK-60 Win7 LUA/Non-Admin Application Integration Engineer. The course is designed to give you a solid background on the native Windows XP application runtime environment, bring you up to speed on the Windows 7 runtime environment and then teach you how to get applications to run on Native Windows 7 without admin rights. Even if you are planning to use application virtualization, up to 25% of your application portfolio may not be able to be virtualized. Here is the course outline. Deployment ReadyHere are the command line options and features that make it a robust solution:
Other Features
Limitations and Features
Customization ServicesIf you wish to have this script licensed or customized for your organization, please use our Contact form to make your request. SubscribewareTo get your copy of this top quality script we only require that you subscribe to a list (including confirming your email address). As with all our lists you can easily unsubscribe at the bottom of any future mailing. UpdatesUpdated: 11/16/10 to Version 2.3, which included these changes:
|
