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.
Related
I am developing a program for Windows which consists of two components:
A kernel driver (signed with an EV certificate)
A user-level GUI component, the .exe file (written in Delphi).
The .exe requires to be run elevated, in order to start the driver and perform other elevated tasks.
How can such a program be automatically run on Windows startup without displaying UAC prompt?
I saw that many similar applications, such as Anti-Malware programs, are able to startup elevated, without UAC prompt.
I am considering the following options, and would be grateful if you can point to the right direction:
1. Set driver startup as automatic, launch .exe from kernel service
However, my research indicates that there is no documented way to start a user-level process from the kernel.
2. Create a separate user-level service which will start the .exe
I read that user-level services are exempt from UAC.
A possible approach would be to create an automatic startup user-level service, which just runs the .exe process (using CreateProcessAsUser()) and then terminates itself.
3. Convert the .exe program from a Delphi GUI application to a user-level service
Similar to option 2, but instead of creating a separate .exe for the service, we are converting the current GUI application to work also as a service.
I found some documentation about this on this StackOverflow thread.
However, this approach seems more complicated then creating a separate dedicated service.
4. Does an EV certificate provide some advantage to allow this task?
5. Is there any better way other then the above mentioned ones?
As it was pointed out by Sertac Akyuz in his comment you should use windows Task Schedluer for this.
With Task Scheduler you can create a task that will run at user logon and run your EXE with highest privileges available.
And when I say highest privilege available I mean the highest privilege of current user when you specify a group of users in When running the task, use the following user account field provided that current user is a member of that group. So if current user does not have sufficient right to execute programs with elevated privileges the task will execute your application with standard privileges.
But as field name suggest you can also specify that this task will always run your application using a specific user account meaning that it will use that account privilege levels instead of of the current user account.
Any way using task scheduler to execute GUI application that comes with some drivers is quite popular. For instance ASUS uses such approach to launch their AI Suite program that allows monitoring and tweaking various settings of their motherboards. Here is how such task is configured on my computer.
PS: I have purposely chose to show you task properties for ASUS AI Suite as it is actually made with Delphi
Let's say app.exe has been built with requireAdministrator manifest as detailed here (this is really needed for a reason that would be out of topic here). When launching the app, when Windows UAC is enabled, there is a normal prompt:
Now this application needs to run on Windows startup: in an Options dialog, there is a "Launch at Windows startup" checkbox that can be checked or not. When checked, it adds a key in the registry in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
to enable this "launch on Windows startup feature".
Problem: At Windows startup, when app.exe is (automatically) launched in background, there is this UAC dialog box (see screenshot before), which is annoying for the user.
Question: How to make that app.exe can be launched 1. with requireAdminstrator 2. silently at Windows startup ?
What is the clean way to do this? Lots of software do this (indexing software that both run on background since Windows startup, and don't show such a dialog box).
Note: I would like to avoid TaskScheduler method if possible: https://www.sevenforums.com/tutorials/11949-elevated-program-shortcut-without-uac-prompt-create.html
The indexing software "Everything" does show such a dlalog.
The others you are thinking of run only services with admin rights, not UI.
Running a service requires the software to be architected with that intent, ordinary user applications can be started with the service rules with the help of the "at" service, which you already know how to do (Task Scheduler).
You can substitute some other service for Task Scheduler, at the risk of annoying the user through needless duplication, waste of resources, and likely new security flaws.
Set aside your preference, and use Task Scheduler.
Or remove the background parts of your app and write a service to do those instead.
And be very careful when giving your code administrator rights. Any bug can result in subverting the entire security infrastructure. With great power comes great responsibility.
Is there a way to find out what privileges my application needs in order to run in a Windows 7 environment?
I have a Delphi application that is using BDE and ODBC for database connectivity. This application works on most computers with Windows 7 running on a normal user account. However on some computers it only works on accounts with administrative privileges and is not working correctly on normal user accounts. I suspect it's a permission problem. The computers also are running in Active Directory.
I tried to find some informations using Process Monitor from SysInternals, however the output for me is too advanced. The process monitor log for two runs of my app (1. successful with administrative rights, 2. unsuccessfull on normal rights) had over 22k lines and i could not find the answer (needle) in the process monitor log (haystack).
What could i do to determine the privileges that my app needs in windows 7?
Use the Standard User Analyzer from the Microsoft Application Compatibility Toolkit.
The Standard User Analyzer (SUA) tool and the Standard User Analyzer
Wizard (SUA Wizard) both enable you to test your applications and to
monitor API calls in order to detect potential compatibility issues
due to the User Account Control (UAC) feature in the Windows® 7
operating system.
UAC, formerly known as Limited User Account (LUA), requires that all
users (including members of the Administrator group) run as Standard
Users, until the application is deliberately elevated, by using the
security prompt dialog box. However, not all applications can run
properly with the Standard User role, due to the application requiring
access and privileges for locations that are unavailable to a Standard
User.
Aaron Margosis has a tool called LUA Buglight that is designed to help track down issues related to privileges.
You can download the latest version from this blog post:
LUA Buglight 2.1.1 with support for Win7/2008R2 SP1
It is similar in concept to the MS Application Verifier. However, in practice I found LUA Buglight much easier to use and understand. Same with ProcessMonitor. It will monitor your process in a similar way but only report actions that failed as a normal user but succeeded as a admin user.
There is no documentation but it is simple to use. From the main GUI window select your Exe and let the BugLight program launch it. You need to be running in an Admin account with UAC enabled. Run your program though the steps that fail when you are not an admin. When you are done click on the Stop Logging button to see a report that lists what calls would have failed without admin rights.
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 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.