Let me start by saying I know next to zero about Windows. My understanding is that processes in Windows get their privileges from a process-level token, which normally would identify the user started the process, but may differ as is common for system tasks, correct? This is somewhat akin to Linux processes having real and effective user and group IDs (it may not be appropriate to make analogies to Linux, but it's all I know). Also, as far as I know, a user can run a process as another user using runas.exe (similar to sudo in Linux). And of course they'll be prompted for the credentials of the user they want to run the process as, and as long as they know the credentials no special permissions are needed, correct?
Now, there is a user right called "Replace a process level token", which according to the docs:
Users with the Replace a process level token user right can start processes as another user if they know the user’s credentials.
Emphasis above is mine. So my question is: if someone knows the credentials for a given user, they can always run a process as them (either using runas.exe or just by logging in as them). What's the purpose of the "Replace a process level token" user right, and what's the security impact of it?
Related
I am trying to find the current (logged in) users name. The script looks for a particular user and changes the network configuration.
The script is started by a LaunchDeamon in /Library/LaunchDeamons.
I am not able to find a way to get the users name who is logging, so if I login as Tom when I call the script the username is root.
Can one one suggest a way to get Tom?
A LaunchDaemon is a system process. It may run when no one is logged in. If you want something that runs in a user's context, you likely want a LaunchAgent instead.
Note that "the current (logged in) user" is somewhat poorly defined because there may be fast user switching (so multiple logged in users), and users may login without a GUI session (via SSH for instance). If you use a LaunchAgent, there may be multiple copies running (and if no user is logged in, there may be no copies running).
For your example, you may just be looking to fetch current login session information (though remember, if you're a LaunchDaemon, then there may be no login session currently). This is best described in Multiple User Environment Programming Topics. In particular, look at "Getting Login Session Information."
In some cases it may be preferable to let a central system daemon communicate with per-session agents. One easy technique for that is NSDistributedNotification, particularly if data only needs to go in one direction. If you need more complex interactions between a system daemon and the user sessions, you should investigate XPC services, which are designed for that kind of problem. See "Creating XPC Services" in the Daemons and Service Programming Guide.
System-level programming, especially things involving user sessions, is exceedingly subtle on OS X (particularly compared to Linux). You should study the Daemons and Services Programming Guide carefully before undertaking it. Things that sound very simple turn out to have many corner cases and surprises. Fast user switching, non-local accounts, mounted home directories, privilege separation (particularly post-10.7), the incredibly vagaries of launchd.... It's all quite manageable, but definitely important to spend some study time before diving in.
OS X allows multiple users to be logged in at the same time. If you are trying to get the name of active console user, the script given below might help.
LOGGED_IN_USER=`stat -f%Su /dev/console`
You cannot as launch daemon runs in the system context and not user context.
As per Apple:
Most daemons run in the system context of the system—that is, they run at the lowest level of the system and make their services available to all user sessions. Daemons at this level continue running even when no users are logged into the system, so the daemon program should have no direct knowledge of users. Instead, the daemon must wait for a user program to contact it and make a request. As part of that request, the user program usually tells the daemon how to return any results.
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.
I need to ShellExecute something as another user, currently I start a helper process with CreateProcessAsUser that calls ShellExecute, but that seems like too much of a hack (Wrong parent process etc.) Is there a better way to do this?
#PabloG: ImpersonateLoggedOnUser does not work:
HANDLE hTok;
VERIFY(LogonUser("otheruser",0,"password",LOGON32_LOGON_INTERACTIVE,LOGON32_PROVIDER_DEFAULT,&hTok));
VERIFY(ImpersonateLoggedOnUser(hTok));
ShellExecute(0,0,"calc.exe",0,0,SW_SHOW);
RevertToSelf();
CloseHandle(hTok);
will just start calc as the logged in user, not "otheruser"
#1800 INFORMATION: CreateProcess/CreateProcessAsUser is not the same as ShellExecute, with UAC on Vista, CreateProcess is useless when you don't have control over what program the user is executing (CreateProcess will return with a error if you give it a exe file with a manifest marked as requireAdmin)
#Brian R. Bondy: I already know this info (And don't get me wrong, its good stuff), but it is off topic (IMHO) I am asking for a ShellExecuteAsUser, not about starting processes as another user, I already know how to do that.
The solution really depends on what your needs are, and can be pretty complex (Thanks fully to Windows Vista). This is probably going to be beyond your need, but this will help others that find this page via search.
If you do not need the process to run with a GUI and you do not require elevation
If the user you want to run as is already logged into a session
If you need to run the process with a GUI, and the user may, or may not be logged in
If you need to run the process with elevation
Regarding 1:
In windows Vista there exists something called session 0 isolation. All services run as session 0 and you are not supposed to have a GUI in session 0. The first logged on user is logged into session 1. In previous versions of windows (pre Vista), the first logged on user was also ran fully in session 0.
You can run several different processes with different usernames in the same session. You can find a good document about session 0 isolation here.
Since we're dealing with option 1), you don't need a GUI. Therefore you can start your process in session 0.
You'll want a call sequence something like this:
LogonUser, ExpandEnvironmentStringsForUser, GetLogonSID, LoadUserProfile, CreateEnvironmentBlock, CreateProcessAsUser.
Example code for this can be found via any search engine, or via Google code search
Regarding 2: If the user you'd like to run the process as is already logged in, you can simply use: WTSEnumerateSessions, and WTSQuerySessionInformation to get the session ID, and then WTSQueryUserToken to get the user token. From there you can just use the user token in the CreateProcessAsUser Win32 API.
This is a great method because you don't even need to login as the user nor know the user's username/password. I believe this is only possible via a service though running as local system account.
You can get the current session via WTSGetActiveConsoleSessionId.
Regarding 3:
You would follow the same steps as #1, but in addition you would use the STARTUPINFO's lpDesktop field. Set this to winsta0\Default. You will also need to try to use the OpenDesktop Win32 API and if this fails you can CreateDesktop. Before using the station and desktop handles you should use SetSecurityInfo on each of them with SE_WINDOW_OBJECT, and GROUP_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION.
If the user in question later tries to login, he will actually see the running process.
Regarding 4:
This can be done as well, but it requires you to already be running an elevated process. A service running as local system account does run as elevated. I could also only get it to work by having an authenticode signed process that I wanted to start. The process you want to start also must have a manifest file associated with it with the requestedExecutionLevel level="requireAdministrator"
Other notes:
You can set a token's session via SetTokenInformation and TokenSessionId
You cannot change the session ID of an already running process.
This whole process would be drastically more simple if Vista was not in the equation.
If you need ShellExecute semantics you can feed following:
C:\windwos\system32\cmd.exe /k" start <your_target_to_be_ShellExecuted>"
to CreateProcessAsUser and you are done.
You can wrap the ShellExecute between ImpersonateLoggedOnUser / RevertToSelf
links:
ImpersonateLoggedOnUser: http://msdn.microsoft.com/en-us/library/aa378612(VS.85).aspx
RevertToSelf: http://msdn.microsoft.com/en-us/library/aa379317.aspx
sorry, cannot hyperlink URLs with "()"
Why don't you just do CreateProcessAsUser specifying the process you want to run?
You may also be able to use SHCreateProcessAsUserW.