Is there some way to launch a process in non-elevated way from an elevated one. My setup is launched elevated and when it finalizes, it will just launch the main application. Because the setup is elevated, the main process will be elevated as well which is not desirable. What is the best solution to this?
That's a problem, Vista/Win7 don't appear to have an API to obtain the unprivileged user token you need to call CreateProcessAsUser(). The only solutions I've found involve using the task scheduler to launch the program. That doesn't strike me as very practical.
An easy solution that jumps to mind is to use a small non-elevated helper process. It can in turn launch the elevated setup process and wait for a confirmation from that one to launch the non-elevated one. The handshake is simple enough to do this with a named mutex.
The only way to do this without hacks is to have two processes (Can be implemented in the same .exe)
Instance A starts Instance B with ShellExecute and the runas verb.
B does the installing, when its time to start your app on the "finish page", it uses some form of inter processes communication (RPC, shared memory+events etc) with A telling it to start a process on its behalf.
This seems like a nice way to do it, provided you don't care about situations where the Shell is not running (e.g. possibly some Terminal Services application-only setups, perhaps, though I'm not sure):
http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/
It gets an interface to Explorer.exe, which should be running in the user's normal context, and asks Explorer to execute a command in its behalf. This is done just using simple, documented COM interfaces and without having to mess around with process tokens or code/DLL injection.
Related
I'm having the following setup: The DLL I'm writing is loaded dynamically at runtime and offers some API-like functionality to the host application. The host application is not running with admin rights (and therefor my DLL isn't either).
Some tasks my DLL needs to fulfill need admin rights though, specifically I have to save and copy files to the program files folder.
My current approach is to launch external applications via ShellExecute and the "runas" verb, which triggers the UAC prompt. This especially means that multiple subsequent actions triggered by the user will always result in an additional UAC prompt, which could be pretty annoying.
So the idea would be to launch a separate, elevated process once, which then runs in the background and receives the respective commands and executes them. This brings me to my question: Which methods of communication are even possible between an unelevated process and its elevated child process? Access to stdin seems to be forbidden due to obvious security reasons, but what about named pipes or shared memory? Do the same restrictions apply?
I am searching for a way to close a process running under any user by a windows service running under the system account. I've nearly tried everything but I could not find any solution except killing the process.
Why can't I kill the process?
I can't kill the process uses a tray icon. If I kill the process, the tray icon won't disappear.
What I've tried so far
I've already tried to use global eventhandles (did not work because the child process got extremely laggy).
I also tried to use PostMessage/SendMessage to communicate with the process. That solution did not work because a windows service can not interact with any user interfaces,...
I found another question (here on stackoverflow) which describes exactly my problem: Close a child process from a windows service.
This question does not contain a nice solution.
First of all I don't use C++ instead of C#. The next problem is, that the child process uses a mouse hook. So it has so run very fast without many overhead. Otherwise it would get laggy which would mean, that the mouse would lag on the whole system.
So is there really no simple solution to close a process from a windows service?
A service can use SetProcessWindowStation() and SetThreadDesktop() to attach to the interactive desktop of the target process before then sending messages to the target process.
Alternatively, the service can use CreateProcessAsUser() to run a new process in the same session as the target process, and then that process can send messages to the target process.
We have a native GUI application which runs on a windows machine, and recently we have found out that the application terminates unexpectedly. After days I have found that this is happening because the application is run by explorer.exe and it gets killed unexpectedly, random somehow, so it causes termination of all child processes including our application.
Is there a way to invoke/call our app as system process (not with explorer.exe)?
Also assume that application/user has administrator access too.
Thanks in advance.
Killing explorer does not in general kill other processes. This is very easy to verify yourself by killing explorer from the task manager. Notice that other processes stay alive when you kill explorer. Something else is killing your process.
If killing explorer leads to your process dying, then the obvious explanation is that something in your process is leading to its death. In other words the problem is most likely in your code, and you need to work out what that problem is.
Also note that explorer isn't really a special "system process" as such. It's just a normal process that that runs under the logged on user's token.
You may need to give some hand of a OS services, then run the service as admin(run as system boot), then start he application from the service ,this will ensures you the app will started as admin and without the explorer.exe(as child)
I have an Avast antivirus and it has a process "AvastSvc.exe". If I try to end/kill that process in Windows Task Manager, then a windows with the following messages appears: "Unable to Terminate Process", "The operation could not be completed.", "Access is denied". Trying to end some system Windows processes (like winlogon.exe) may feature the same behaviour (although once I managed to kill winlogon.exe and got my machine hanged!).
I want my application (possibly, converted to a service) behave in the same way. How can I do this?
Disable Windows Task Manager so he cant kill my process is a similar question which has many interesting answers, but they don't seem to feature the technique which is used by the above antivirus and results in "Unable to Terminate Process" message.
http://forums.codeguru.com/showthread.php?t=503337 has a solution on how to prevent stopping a service (eg, via services.msc console), but I need preventing ending/killing its process in Task Manager.
I am writing the app in C++/winapi, no CLR/.Net, under Windows 7.
UPDATE on permissions:
Antivirus process AvastSvc.exe is owned by "system" account. However, I have other processes owned by "system" account, and they are killable and antivirus is not. Also, I compared executable permissions and owners of antivirus process and ones of killable processes, and I don't see any difference.
UPDATE on user control and purpose of the software:
The software functionality is somewhere between that of system and business software. The nature of the software requires it to run on a permanent basis. The application itself will have a "turn off" action, and we want to encourage users to use it and discourage them from killing the process (it's similar to what antiviruses do). I understand that it's not possible to completely prevent users from killing it, but I want to make it harder. This question is specifically about the way described above ("Unable to Terminate Process") which some services (like Avast) use to prevent killing their processes. It is sufficient for me to achieve just the same behavior. Also, users will be able to just uninstall the software if they don't like it/don't need it anymore.
This is not achieved through code (well, it might be for critical Windows system processes, but you are [probably] not writing components of the operating system), but rather through access permissions.
You can demonstrate this by elevating to Administrator and then attempting to kill Avast's process. It should succeed this time. Alternatively, you can take ownership of the executable (and possibly the folder in which it resides), then try to kill the process. Again, it should be successful.
Windows does not allow applications to exert more power over the computer than the user. If you own the machine and have the appropriate permissions, you can do anything you want, including terminating a running process. Thankfully, there is no way for you, as a developer, to block this.
The user is always in ultimate control. Attempting to create an alternative situation is a battle that virus and other malware developers fight—and lose—regularly. Since I'm not interested in helping anyone write malware, that's all I'm going to say about that.
And other than writing malware, I can't imagine what the motivation for this "feature" in an application would be in the first place. If you're simply trying to prevent regular users from killing a process that is critical to a business system, then you should just demote the privileges of the standard user accounts so that they will not be able to tamper with such things. As such, this is probably a job for Group Policy, rather than code.
I found that the function ProtectProcess() supplied in Prevent user process from being killed with "End Process" from Process Explorer results exactly in the effect I was looking for.
Hide your process by removing it from the eprocess structure
Issue persistent I/O requests that cannot be cancelled or completed by other processes
Create threads to debug your own process
Create separate process/es from memory that monitors the main process and re-starts it from memory once terminated by another process
I have a single thread that I'd like to run as an administrator in my application. The rest of the application I can happily run as the default user level (asInvoker). Is this possible? I notice there is an "ImpersonateLoggedOnUser" function. Can I somehow use this to log the administrator on and then get the thread to impersonate that person?
It seems as though this ought to be something pretty trivial to do ... but there doesn't appear to be any obvious way to do it. Can anyone help me out?
Edit: So if I have to fire off a seperate process is there any way I can CreateProcess a new process and have it launch from a specific entry point. I can, of course use command line processing to do it, but i'd really rather I could stop the user from entering the command line and starting an unclosable process!
No, elevation is per process, not thread.
If the rest of the application has to run non-elevated, you could run yourself elevated with some parameter (myapp.exe /uac "ipcparamhere") and use some sort of Inter-process communication to communicate back to the "main instance" of your app. (If the elevated process only performs a simple operation, you could probably check for success by using the exit code of the process)
This is not possible. You'll need to gain admin privileges by including a manifest in the app. Google "requireAdministrator" to find the manifest you'll need. Your user will probably quickly tire of doing this over and over again, your best bet is to spin-off the task that requires these privileges into a separate process. A service for example.
You can launch a separate exe and have a manifest on it saying it requires administrator. Then be sure to launch it with shell execute, which uses manifests, and you're all set. As a thoughtful touch, put a UAC shield on the button that kicks off that thread. (Send it a BCM_SETSHIELD message if you're doing this all by hand.)
You can decided whether you want a visible window or not on the separate process. Meanwhile the user can still drag and drop into the main app.