Service Isolation

Session Separation

Ever since Microsoft incorporated Citrix's MetaFrame technology in Windows with Windows NT 4.0 Terminal Server Edition, Windows, or at least Windows in the NT family, has had the notion of sessions. A session is basically a set of applications and, usually, a desktop connected to a user. Examples of where you've seen probably seen sessions before include:

Terminal services sessions Many people can run sessions on a single Windows Server box via Terminal Services. These sessions don't "leak" from one to another, as the underlying session mechanism keeps them apart. Different users can have different desktops and applications even though they run on the same machine, and are totally unaware of each other.

Remote Desktop and Remote Assistance These are implementations of Terminal Services on XP and Vista and create different sessions, although they're much more limited than the functions offered by Terminal Services on a Server system.

Fast User Switching XP and Vista can keep track of multiple logged-on users via Fast User Switching. Each logged-on user gets a session in Fast User Switching.

Sessions are numbered from 0 onward, and in Windows before Vista session 0 was known as the "console session." With Vista Fast User Switching, the first person to log on gets session 1, the next session 2, and so on. (That of course assumes that no one logs off; if one person logs on and then off, and then another logs on and off, then they both get a session numbered 1, but of course they won't share desktops.)

In Vista, Microsoft moved all of the services into session 0, and added a few new rules about life in session 0. First, session 0 does not have a user interface of any kind. It can't communicate with the video hardware. It can't pop up messages to users in the other sessions. The only way that it can communicate with other sessions is via the Remote Procedure Call (RPC) protocol, which is a secured method for applications to talk to one another.

Putting services into session 0 and keeping users out of that session has another effect: it makes a common approach to privilege escalation impossible. Over the years, bad guys have created a number of tools whose purpose was to let someone with limited powers-a standard user or even a guest-to "amp up" their power to that of System by taking control of some badly written service. For example, one of the most common approaches was to simply use the at.exe scheduler to start up a command prompt, which would then be running as LocalSystem. Well, that won't work anymore.

And as is so often the case with increased security, compatibility suffers. Some kinds of drivers-print drivers in particular-are loaded by a service (the Print Spooler service, in this case) and so live in session 0. That means that if a printer driver were to try to raise a dialog box, perhaps to announce an error or seek some user input while installing, then that attempt to contact the user would fail. There is, however, a temporary-Vista-only, it won't appear in subsequent versions of Windows-workaround called the "Interactive Services Detection Service." You can start it on your system by opening an elevated command prompt and typing net start ui0detect, and that's a zero in that key name, not the letter "O." Or you can tell Vista to make the Interactive Services Detection Service always start automatically by typing

 sc config ui0detect start= auto 

Remember that there must be a space between "start" and "auto" it's a quirk of sc.exe 's syntax.