I had to delve into this because the code that worked fine on Windows 2003/XP doesn't on Windows 7. Application launched by the use of CreateProcessAsUser fails with 0xc0000142 error code. The difference between my old code and one available from MSDN at Starting an Interactive Client Process in C++ is that I didn't set up privileges and to Window Station and desktop. I've updated my code according to the example, but I would very much like to understand which change in newer Windows made running processes in interactive Window station a requirement?
At least part of the requirements derive from the change to run interactive processes in a different session from services. This was done so that applications could not run 'shatter' style attacks against privileged services. More information is available here.
Related
I'm developing a Windows application that must execute other GUI programs with privileges (executed as administrator).
Scope
My application is a "daemon", a long-running process that it will be launched with no user action;
My application must be executed as administrator (privileges elevation);
Processes executed by my application must be executed as administrator and must display on the screen.
Approach
Firstly, I developed my application as Windows service. I thought that it was the best way to run programs with privileges but services can't run programs that use the GUI session.
This restriction has been introduced by Microsoft with Windows Vista. An article from Microsoft - Impact of Session 0 Isolation on Services and Drivers in Windows - explains these changes. I tried to change the user who runs my service but this isolation appears to apply for all services.
Purpose
So my question is "What's the best way to run a program that it will launch another program with elevation of privileges (executed as administrator) with no action from user ?"
Currently, the only once idea to solve my problem is to register my application into Task Scheduler but I think that it probably exists a best way.
Windows Services have not been designed to interact in current session (user session). Services are running into Session 0 since the deployment of Windows Vista.
Explanations about this changes can be found in "Impact of Session 0 Isolation on Services and Drivers in Windows".
I have found another Microsoft post "Launching an interactive process from Windows Service in Windows Vista and later" but we can read at the beginning:
The first thing you should do about it is that, don't do it. There are many limitations, bad implications and restrictions involved into it.
Windows Services are definitely a wrong solution for this use case. The unique solution that I can found is the Task Scheduler.
I have a rather difficult to manage Windows closed-source Windows GUI application. It's messy (leaves files all over the place) and has a convoluted installation process.
It has been proposed that we containerize the application, but can this be done?
For UNIX applications there's an easy pattern - just give the app access to the port of the X11 server, and allow the app to write to that, but is there a Windows equivalent? Is there any way at all to containerize a Windows application but allow it to generate windows in the host Operating System's desktop?
If this is possible, are there any handy recipes to get started with this?
Currently, It's not possible to containerized Windows GUI application on a windows host.
From the blog Insider preview: Windows container image
Lars Iwer [MSFT] writes in the comments below the article:
"In the container image as it is right now, GUI elements will be rendered in session 0. UI automation should work with that (e.g. programmatically searching for a window etc.)."
So according to my understanding, you can run GUI apps but the rendered elements are not shown on any desktop which will only work for UI automation work but not for user interactive application.
Session 0:
Session 0 is reserved exclusively for services and other non-interactive user applications. Users
who are logged on to Windows and their user applications must run in Session 1 or higher.
- User interfaces in Session 0 are not supported. Processes running in Session 0 have no access to the graphics hardware thus user interfaces cannot be directly displayed on the monitor.
We have a windows service that gets installed and runs on users system in the background, but on some windows machine user get an error "A device or program has requested your attention" This is specific to Windows 7.
This is because when we are installing the .exe on the user machine using MSI(created with WIX), the installer job I believe runs on Session 0, and when any prompt appears the user is prompted that a program has requested attention and he gets switched to Session 0. Can we suppress messages for installer or exe running in Session 0.
Thanks.
To fix this you will have to determine what UI is shown if the user switches to Session 0, what shows it, and how to remove it.
Services run on Session 0. Before Windows Vista, they could interact with the desktop, so many did. Chances are your service is trying to show some UI. Upon detecting this, Windows is trying to help you out. Fix the service to avoid showing UI, and the message will go away.
It's plausible that this could also occur for a deferred custom action in the system context (as those are invoked by the Windows Installer service), but I've never run into this scenario. If so, the fix is the same: make that action not show any UI.
Michael's correct, but I want to expand on it a little.
The issue isn't primarily about session 0 or services. It is about anything that tries to show a UI that is not part of the interactive user's current session. The main problem is the shatter attack where (for example) something running with the system (or otherwise privileged) account shows UI to the (perhaps limited) interactive user. The window into the privileged process is a security hole. As a result, attempts by an install to run custom actions with the system account (deferred CAs) that show UI are an issue, as are services. Session 0 is really just part of the implementation that is intended to address the security issues.
So yes, address UI attempts from your services and from (primarily deferred) custom actions in the install.
When a setup program(built by like Inno Setup) does launch a process, the process always be run as administrator privilege. -because setup program had been run as admin.
I want to run the child process as current user's privilege.
Is there a good way?
This question comes up every 3 or 4 months internally at MSFT.
The answer that the security folks give is: You can't. When the elevated process token is created, there are changes made to the token that can't be undone.
Your best bet is to have a launcher application that runs your elevated setup program and then when the elevated setup program is completed, turns around and runs your child process.
As a launcher you can use the portable powershell app deployment kit (Link). You can edit the deploy-application.ps1 and use Execute-ProcessAsUser to run applications/scripts with the current user even when you launched the powershell app deployment kit as admin
Although it is not considered best practice (or even good practice), it is possible to launch a medium IL process from a high/admin IL process:
See this post on codeproject
I can confirm that this code works on Vista 32 and 64-bit with and without UAC enabled.
I'm having a lot of problems trying to start an application as administrator on an application I'm writing when running it on XP Embedded.
The application runs as the shell for a limited user account and is touch-screen and keyboard-less with one user command being to run the touch screen vendor's calibration tool. This must be run as administrator.
No problem I thought, add user and password information to the ProcessStartInfo and all should be fine. No. The error I get is:
System.ComponentMode.Win32Exception: The specified service does not exist as an installed service.
From some investigation, I've found that:
My Process starting code is correct:
any application can be started successfully on XP Embedded when run as the limited user
any application can be run as Administrator on my own laptop
on XP Embedded, any application is regarded as being a service in the same way, including notepad
if I attempt to start a program from within process explorer, I simply get "Unable to execute process: Access is Denied"
I'm not an XP Embedded expert in anyways so I'd very much appreciate some help. I suspect that there's a configuration setting that has been set when building the XP image that specifically denies access to process creation and that the errors I'm being reported are actually mis-reports from software that's not assuming XP Embedded error codes.
Unfortunately, the people who make the base image aren't around right now so I can't get the current settings.
Thanks in advance if anyone's ever seen this before!
Kev
For the record, it turned out that the "Secondary Logon" service wasn't installed in the image.
The code I had reached down eventually into either CreateProcessWithLogonW or CreateProcessAsUser which ultimately depend on this service running. The "specified service" error was spot on, but not about what I thought it was about. No idea why I got that particular error from Process Explorer.