In windows (in general), does process owned by a particular user exits when the corresponding user logs off (but computer is still on?)
Is the behavior consistent accross Windows / Windows Server ?
Yes, a process initiated by the user (or by the system on behalf of the user) is terminated when that user logs off. If they only "switch users" or "lock" the computer, the processes reaming running in memory, as normal (though they may lose priority in the queue to process initiated by or on behalf of other users concurrently logged in).
As far as I know, this behaviour is the same on Windows Server, though I imagine that it the priority queue is even more skewed in favour of system processes when a user is not actively logged in.
Related
It appears that cross process messages are allowed in Windows, and while Windows appears to have protection so that a lower process can't inject a message to a higher process, say they are at the same level at the time and a message is created with an invalid pointer that gets updated. Isn't that a potential issue? For one, crashing apps or corrupting data, or two, maybe exploiting an app that may elevate later?
TIA!!
Cross process security risks are all about using the enhanced privileges of other processes to do something that your process cannot do. Privilege isolation of the message system protects against that.
crashing apps or corrupting data
Processes can terminate other processes at the same privilege level. Being able to send messages to other processes at the same privilege level adds nothing new.
exploiting an app that may elevate later
Processes cannot elevate later. Elevation happens as part of process creation.
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.
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.
How does fast user switching affect a windows service? Are the services suspended or do they keep running in the background when a different user logs in?
On Vista, services run in session 0. This session is always running. User sessions are session 1 on up. Even as users connect and disconnect from sessions, log on to new sessions, and so on, the services keep running and session 0 is never torn down. The only effect on services is they (optionally) receive notifications such as session connect, log on, and so on.
On XP, services run in session 0 and so does the initial user who logs on. This session is never torn down, and may or may not have an interactive user connected to it. Besides this, the behavior is the same as Vista.
They keep running; they run as their own users (whatever you set).
Windows services run in the background even if no user is logged in. Switching between users should have no impact on a properly written service.
I maintain a variety of managed userlabs on a university campus. These machines all currently run Windows XP and we have a windows service that is used to "lock" a machine by blocking any keyboard or mouse input. The locking happens during our scripted OS installation so that users aren't able to accidentally halt or break the process. It is also used to prevent users from logging into machines until they are checked out at the front desk of a given lab. Ctrl+Alt+Del is blocked via a keyboard filter driver and the rest of the keys and mouse are currently blocked using the BlockInput() function from user32.dll.
In XP, the service runs as Local System and the checkbox for "Allow service to interact with desktop" must be enabled from the BlockInput() call to succeed. Under Vista, this no longer works I'm guessing because of the Session 0 isolation changes. The call succeeds, but input is not actually blocked.
The keyboard filter driver still works just fine and we can use that to block the whole keyboard instead of just Ctrl+Alt+Del. But I'm at a loss as to how we're going to block the mouse now. I'm not even entirely sure the Session 0 isolation is to blame.
Can anyone recommend a fix or a workaround to allow us to block mouse input from a service in Vista and beyond? I've looked for alternative win32 API's without luck. Assuming Session 0 isolation is to blame, is there a legitimate way to call the function from Session 1 or would that sort of defeat the purpose of the isolation? Will I have to rely on an elevated companion exe that runs on user login and communicates with the service?
From a service, you can use WTSEnumerateSessions to get all logged on user sessions, WTSQueryUserToken to get the logged on user's token, and then use CreateProcessAsUser with that token to get code running on the user's desktop. This has the disadvantage that the code will run as the logged on user. Since all input is disabled, this is probably safe enough and is at least as safe as the existing XP solution.]
EDIT: BlockInput requires a high mandatory integrity level. You could try adding this group to the token, but then you have code with higher privileges running on the desktop and potentially open to attacks.
An alternative might be to use your service just to disable all HID class devices on the machine.