Sessions, Window Stations and Desktops.
A session consists of all process and
other system objects that represent a
single user's logon session. Sessions
contain Window Stations and Window
Stations contain desktops.
The above is from http://blogs.technet.com/b/askperf/archive/2007/07/24/sessions-desktops-and-windows-stations.aspx
(Similar articles say the same thing, e.g. blogs.technet.com/b/askperf/archive/2007/04/27/application-compatibility-session-0-isolation.aspx and blogs.msdn.com/b/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx)
I've always understood Sessions and logon sessions to be one and the same thing.
However, reading p. 474, Russinovich and Solomon, Windows Internals, 5th edition, it says (penultimate paragraph):
The CreateProcessWithLogon function
also creates a token by creating a new
logon session with an initial process,
which is how the Runas command
launches processes under alternative
tokens.
So Runas creates a new logon session. If we use Runas to run Notepad under a different user's credentials we see it appear on the desktop. So Notepad is running on the same desktop as everything else. (This is, as far as I understand it, the default desktop in Window Station Winsta0; the interactive window station.) So what we have now are two logon sessions associated with the same Session (the thing that contains window stations). So Sessions and logon sessions would not appear to be one and the same.
Can anybody confirm this please?
Confused
There are indeed two types of sessions here. Here's my understanding of how they work.
A logon session[2] is managed by the Local Security Authority[2], and manages the scope of a user logon. These are created primarily by the winlogon process, but also secondarily by API functions such as LogonUser, CreateProcessAsUser, and CreateProcessWithLogonW, or by applications that use these functions, such as the runas command.
A logon session isn't tied to any specific Object Manager[2] concepts as window stations and desktops. It's basically just a block of information containing the logon SID and some cached security information about the account. This block of information, this logon session, is what an access token points to.
The other type of session is sometimes called a Terminal Services session, Terminal Server session, Remote Desktop session, logon session (as confusing as that is), user logon session, or user session. Usually, though, it's just called a "session", without further qualification.
This is the type of session that you'll usually hear about, and is what window stations belong to. This type of session came about to support multiple interactive GUI logons, as provided by Terminal Services (now known as Remote Desktop), and is now also used to support Fast User Switching. Sessions provide the necessary isolation between the Object Manager objects associated with each user logon.
I don't spend much time messing with all this stuff, so I'm a little fuzzy on some of the details, but I think this is a pretty fair representation of the overall picture. I hope it clears things up a bit.
Related
When running under Citrix or RDP as an admin, I can see, terminate or otherwise manipulate processes created by other users, or in other sessions. Admins need to be able to do this from time to time so I can't remove that capability from Admin logins, but I'd like to restrict it on certain processes.
Is there a way to change the security and/or privileges of the current process or a process I launch, so that it can no longer see or otherwise manipulate other user's processes? I'd be happy to either change the rights of the currently executing process (which is mine), or launch my process using some method that denies the privilege to the target executable. It's the inverse of Run as Admin.
I thought that AdjustTokenPrivileges might be the key, but I can't seem to find any privileges to remove that relate to seeing other users' processes in the Privilege Constants list.
CreateProcess with an appropriate lpSecurityDescriptor seems like it might do the trick, but I haven't been able to find a good example of the security descriptor, or anything that relates to other users' processes.
Anyone know the secret sauce? Thanks
I have a system service which creates a helper interactive process as administrator so that it can access some desktop-related resources, including the BlockInput() function and NVIDIA's NVAPI functions, which cannot be run from a service. When the logged on user was a member of Administrators, the following worked:
Set privilege levels, including SE_TCB_NAME
Get active session ID with WTSGetActiveConsoleSessionId()
Get logged on user from session ID with WTSQueryUserToken()
GetTokenInformation() with TokenLinkedToken
DuplicateTokenEx() with SecurityImpersonation
Launch process with CreateProcessAsUser()
However, when I have the current logged on session be a standard user instead of one in Administrators, step 4. fails, presumably because the standard user doesn't have an administrative level token linked with it. What's the solution here? I assume I need to get the token of one of the administrator users, but how do I do that? And if that user is not the logged on one, can it still access functionality interactive with the current desktop?
You can duplicate your own token, then change the session on the duplicated token using the SetTokenInformation function to put it into the interactive session.
As you note, running as SYSTEM in an interactive session is discouraged because it gives the interactive user openings to attack your process, potentially gaining elevated privileges. (Search for "shatter attack" for more information.) However, this concern applies equally well to a process running as an administrative user in a non-administrative user's session.
Ideally, you should use a non-administrative process in the interactive session, to perform functions which require an interactive session, while using the service to perform functions which require administrative privilege. There shouldn't be any functions that require both, but if NVAPI breaks this rule, there's not much you can do about it.
Consider launching the process into a specially created (and appropriately secured) workstation in the interactive user's session in order to minimize this risk.
I have developed a C# Windows Forms application that runs in the background as a systray icon and does some stuff when it's clicked. It is supposed to launch when Windows starts and run continously, and a normal user without administrator rights shall not be allowed to shut it down.
What is the best way to do this? I initially intended to run it on the LocalSystem account through Task Scheduler, but then I learned (the hard way) about Session 0 isolation (i.e. the application will run but its UI elements do not show). When I run it with the logged in user, even if it runs elevated, the user can still shut it down through task manager (without requiring elevation).
Is there any way to give a process from LocalSystem access to the UI? I have a winlogon and a csrss process from LocalSystem running in session 1, so I guess it can be done, I just don't know how. Or is there maybe an easier way to disallow users to shut down a process of their own through the task manager? The only other option I can think of is to create an extra Windows Service that keeps polling if the app is running, and immediately launches it again if someone kills it - but that seems incredibly clumsy (also, I want it to stay dead when it crashed by itself, to avoid a single bug causing infinite loops of process creation).
Deponds on why they can't shut it down.
The natural way to go would to have created a service, started by a high priv account, and then had the desktop app just show what it was doing.
If there's something that they should see, but don't becasue they aren't running the service monitor app. (and acknowledge message back to the service), send them an email, send their boss an email, send yourself one and then go shout at them.....
Be a lot easier than trying to get the lid back on this tin of worms.
A nice way to make sure the desktop app is ruuning, would be simply to schedule it to run every X, but drop out immediately if it already is or the somethingwenthorriblywrong flkag is set.
Not worth writing a service to check if it's still there, as they could kill that as well, unless you want to make that a service they can't kill. :(
You are trying to be too draconian with this. Add some sort of auditing so you can see it dies or was shutdown, monitor that and deal with any adverse reports. It's a heck of a lot easier, and gives manage something to do...
You can run an administrative process in the user's logon session. One method would be to for a master process (a system service) to duplicate its own token, use SetTokenInformation to change the session associated with the token, and then call CreateProcessAsUser. The lpStartupInfo parameter can be used to associate the process with a particular window station and desktop. It may be necessary to explicitly change the permissions on the window station and desktop first.
HOWEVER, this is a bad idea from a security standpoint, because GUI applications are vulnerable to malicious messages sent from other processes on the same desktop ("shatter attacks").
It would be safer to run the process in the user's own context but apply an ACL to it. This can be done using the lpProcessAttributes parameter to CreateProcess or CreateProcessAsUser, or with the SetSecurityInfo function. I've never tried this, but it should in theory prevent the user from using task manager to close the process.
If you are creating the process from the user's context, then the user will be the owner, so a sufficiently knowledgeable person could change the permissions back in order to terminate the process. If you need to block this hole, using CreateProcessAsUser from a privileged master process (the token can be duplicated from one of the existing processes in the user's session) should (again, in theory) mean that the user is not the process owner.
Another potential issue: if you listen for messages indicating that the user is logging out (in order to exit) such a message could be faked. If you don't then you need to find some other way of exiting when the user logs out. You may need to experiment here, I'm not sure how the system will react.
When using CreateProcessAsUser we pass STARTUPINFO and with lpDesktop NULL, the target is winsta0/default, the interactive desktop of the interactive user.
I wish to target a window station in another session of a second, non-interactive user, say a remote desktop user.
I assume that it can't be winsta0 because that's reserved for the single interactive user.
I am looking at the function list here:
http://msdn.microsoft.com/en-us/library/ms687107(v=VS.85).aspx
I can enumerate window stations on the machine, but how do I identify which window station is connected to which user/process/session?
Each window station is connected to a session
Each process has a target window station
But how, for example if I have a process, or a session ID, do I determine which Window Station it is associated with?
On WinXP/Win2K3 or higher, you could do the following:
Call WTSEnumerateSessions to get a list of active session information (which will also give you the window station name associated to each session).
Pass the session id to WTSQueryUserToken.
Pass the token to GetTokenInformation to get the user's SID.
Pass the user's SID to LsaLookupSids to get the user and domain names.
Also, if you want to identify which session is the active console session, you can compare the session id to the return value of WTSGetActiveConsoleSessionId.
However, I would recommend using the token returned from WTSQueryUserToken to launch a process on the target desktop via CreateProcessAsUser, as Franci mentioned. You'll have to pass it through DuplicateTokenEx to convert it from an impersonation token to a primary token, but it works on WinXP or higher, and Microsoft documents it as the "preferred" way to launch interactive applications from the services desktop on Vista and higher.
You can use GetUserObjectinformation to get the SID of the user associated with that window station.
As for finding the Window Station from a process:
- Get the top-level window handle for the process
- Enumerate the window stations (EnumWindowStations)
- Enumerate the desktops for each window station (EnumDesktops)
- Enumerate the windows for each desktop (EnumDesktopWindows) until you find a match.
Yeah, it's not a straightforward, but it should solve your problem.
Note: On Vista and Win7, the interactive user is not in winsta0. Winsta0 is reserved for the system and services only, the interactive user gets a new windows station and is treated the (mostly) same way as a TS users.
I have an application that can list the opened windows of the current session. It uses the EnumWindows method from the user32.dll.
I would like to run this code from a windows service, but as the service is not attached to a user session, it returns nothing obviously.
So the question is, how can I enumerate the open windows of another user session (e.g. with a specific logon user)?
Similarly to EnumWindows, I also would like to get the foreground window of the user session as well (like GetForegroundWindow works for the current user).
As far as I'm aware, you can't access the windows of one session from another. It's also worth noting that there's not really any such thing as "the current session" - there may be multiple users logged on through terminal services, or XP's fast user switching.
One approach to this would be to add a program to each user's profile with no UI that just communicates with your service. You'd still have to cope with the fact that there could be multiple active sessions, though.
According to this document you can create a process in an other user's logon session using CreateProcessAsUser, and could enumerate the windows there. You will still need some IPC mechanism to communicate with the service.
The accepted answer is not correct.
So the question is, how can I enumerate the open windows of another user session?
You can enumerate the open windows of any session if you're running as a service running as the local System account.
To do this first enumerate the sessions with WTSEnumerateSessions. Then enumerate the window stations inside each session with EnumWindowStations. Then enumerate the desktops for each Window Station with EnumDesktops. Finally you an enumerate the Windows in those Desktops with EnumWindows.
(e.g. with a specific logon user)
There can be many concurrent logged on users via Terminal services or fast user switching.
Similarly to EnumWindows, I also would like to get the foreground window of the user session as well (like GetForegroundWindow works for the current user).
This can be done by launching an app with a found user token in the Session, Window Station, and Desktop. From there you can call any Win32 API like GetForegroundWindow and report the info back to your parent process.
You can learn more about how Sessions, Window Stations, and Desktops work here.