Window stations are a little known but very important security feature designed to sandbox the windowing environment in the operating system. In order to avoid putting ACLs on each window and incurring the wrath of the performance gods by doing access checks on each window message, we simply let windows message each other without any security checks. However, we do so in a private environment known as a window station.

A window station is a secure kernel object that contains a clipboard, a private atom table, a set of desktops, and a set of windows. Each process is tied to one window station, and this association normally parallels logon session assignments. That is, for each logon session there’s a corresponding window station, as shown in Figure 18.1. In fact, window station names are derived from logon session identifiers (WhatIsALogonSession). The window station for Network Service, for example, is Service-0x0-0x3e4$. Occasionally a daemon (IIS, for example) will take window station management into its own hands, but this is the exception to the rule. There is also an “interactive” window station, which always exists even when no interactive user is present. This special interactive window station, hardcoded with the name WinSta0 deserves a bit more attention.

Figure 18.1 Window stations normally parallel logon session boundaries.

WinSta0 is the only window station actually bound to hardware. That is, you can see windows there, and they can receive input from the mouse and keyboard. WinSta0 is also tightly secured, with an ACL that sandboxes the interactive logon session, although from Figure 18.1, you can see that some highly trusted services running in the SYSTEM logon session may also run there, such as winlogon.exe. The ACL on WinSta0 controls what you can do with the GUI at a very detailed level, but, practically speaking, it's an all-or-nothing grant and really only necessary to constrain which processes are allowed to attach to the window station. (It’s possible to change your process's window station affiliation by calling the Win32 function SetProcessWindowStation, or to launch new programs that attach to particular window stations by tweaking the STARTUPINFO parameter to the Win32 function CreateProcess). In this way the ACL on the window station prevents programs in other logon sessions from intruding into your windowing world.

The practical point of having window stations is to avoid luring attacks from daemons¹ against an interactive user. If a process running under a low-privilege account can send window messages to a highly privileged program, it can take control of that program. For one example of how this can be done, read WhatIsALuringAttack. Because window station boundaries normally parallel logon session boundaries, this helps prevent this sort of attack.

So, we have the interactive logon assigned to a window station that’s bound to hardware, but what about daemons (WhatIsADaemon)? Each daemon logon has its own window station, but these are noninteractive (remember, there's only one interactive window station, WinSta0²). A noninteractive window station is not bound to hardware, so if you're a daemon you can create legitimate windows that work just fine—but nobody will ever see them. This is important for some plumbing such as COM apartments. But imagine if, as a daemon, you put up a modal dialog and sat there waiting for someone to press the OK button? You’d be waiting an awful long time! The only way to dismiss a modal dialog in a noninteractive window station is to do it programmatically. For example you could simulate a button press by sending the dialog a WM_CLOSE or a WM_COMMAND message. Knowing this, nobody in their right mind would purposely put up a modal dialog from a daemon, but what about debug builds of C++ apps using the ASSERT macro? Or what if you buy a third party library for use in a daemon you're writing and find out later that it pops up modal dialogs from time to time? This isn’t fun to deal with, so, as a library developer, carefully consider where your component may be used before putting up dialog boxes. That said, if you think you have a legitimate reason for putting up a user interface from a daemon, read HowToDisplayAUserInterfaceFromADaemon.

If you come from a Win9X background, you may be surprised that a window handle isn't valid for use from any old process on the machine. If you're used to using window messages for interprocess communication, then it's time to learn another technique, such as .NET Remoting or COM.

When one process creates another, the new process is placed in the same window station as the old one, unless you write special code to do otherwise (which is extremely rare). So, just like tokens and logon sessions, a new process naturally inherits its parent's windowing environment. Note that starting a service is not the same as simply creating a new process. When a service is started, it is assigned to an appropriate logon session and window station by the operating system, as I discuss in WhatIsADaemon.

¹ Or from interactive users in other Terminal Services sessions.

² Note that Terminal Services adds a twist here: In this case there is one interactive window station (named WinSta0!) in each Terminal Services session.