We have an exe which actually checks the contents of a folder and then kicks off a windows service to do some processing on the files in that folder.
So, we made this exe as part of System start up program so it runs everytime the system reboots/starts.
Now the user is very annoyed as he gets pop up for UAC everytime he restarts. But we need to have admin rights for this exe as it kicks off a windows service. Therefore I researched and found a couple of solns for this prob.
This and This
But couldn't decide which is better and less vulnerable for security implications.
Another potential solution can be in the code of .exe itself detect the system start up and if we have any content in the target folder then only ask for UAC from user and kick off the windows service . Else just don't run the exe. I am not sure how to do this in C++. Any pointers would be helpful. If there is any better solution, always welcome.
You probably want to use Task Scheduler here.
Just create a task as part of the install process, with "When the computer starts" as the trigger, and set the "Run with highest privileges" security option.
The problem is that you're mixing up the system and user sessions.
If the processing of those files is done on behalf of a user, it probably should not be done by a service. What if two users wanted their files processed? What security context should the service use for that? And obviously you shouldn't need Administrator right to process some user files.
If the service is performing some system-level task, it shouldn't depend on a user. And in fact running at startup suggests you want this mode. (User applets start at login, not after reboot). The main problem in your design therefore seems to be that you try to run an app (with UI) at the wrong moment which requires far too many permissions (causing UAC). Redesign the service so that it does all the tasks which require admin permissions, and when installing the service set it to start automatically. This still requires UAC at installation, but that is when UAC is expected.
Related
I want to package programs into an MSI and create Scheduled Tasks (i.e. run on Boot/Startup).
I'm trying solutions available on the market such as Advanced Installer and EMCO MSI Packager, but I get the same error in both:
Verify that you have sufficient privileges to start system services
This means my account does not have the "Login as a service" privilege. However, looking up solutions, you'll find that Advanced Installer offers little help.
Basically, they suggest either (1) hardcoding user credentials, which is obviously unviable or (2) creating a new user with the required privileges, also unviable.
I've created tasks before in plain C++ and it was very easy, a simple
system("schtasks [args]")
Was enough to create tasks, and as long as the program was running after a UAC prompt was accepted, the tasks were successfully created.
So what exactly is the aforementioned error, and how can I fix it, preferably with a solution from the market (it is cleaner than having to manually make a setup.exe, ask for privileges, manually make tasks).
Edit: Any answers that provide some clarity on creating Scheduled Tasks that automatically run elevated (i.e. have access to Program Files, etc) are greatly appreciated.
Edit 2: Setting user to LocalService did not work.
Verify that you have sufficient privileges to start system services is a red herring. It's a generic error message from MSI saying it couldn't start the service. There's a bakers dozen reasons (that I've answered on here: Error 1920 service failed to start. Verify that you have sufficient privileges to start system services )
Here's a couple tips:
DLLs going to Win SXS and GAC don't happen until after StartServices because of a design limitation in MSI. Try installing but not starting the service. Then after it's installed try to start it. If it works, it could be that.
You could be missing files. You can try to run the exe from a command prompt while it's hung and see if it says anything is missing.
The application could be crashing on startup.
I offer free 1 hour consulting sessions. If you can share the files with me I could look at it with you. Look me up if you are interested.
I have a multi-process application that was originally developed in XP and was originally designed with no regard to administrator privileges. We used to configure and sell computers with the software. We are now selling the application by itself, without the hardware, to be installed on user systems in a corporate environment. Currently our software package requires our users to run in administrator mode, which is not making us popular with our customers IT departments.
I have been working to remove items that obviously require administrator privileges (writing to HKLM in the registry, writing to the Program Files folders). However, Windows continues to require administrator rights to run the software. If I deny the rights, it closes with no logs. It has a lot of legacy code and so hints to find where the administrator access is happening has proven difficult.
Is there an easy way to see what is being accessed or done that is hitting Windows 10 admin requirements?
Currently I have removed moved writing of data files I could identify to the Program Data folder or to user documents. (depending on whether I want users to be able to easily find them or not).
Configuration files have been moved to user folders.
Registry key access has been kept to HKLU or read-only in HKLM.
Thank you all for the help. I ended up finding the answer in the C# based launcher for our software, which was starting all processes with the verb "runas" set:
try
{
myProcess.StartInfo.Verb = "runas";
myProcess.StartInfo.FileName = command;
myProcess.StartInfo.WorkingDirectory = workingDir;
myProcess.StartInfo.Arguments = prams;
myProcess.Start();
}
catch (Exception ex){}
I removed the "runas" verb and now the system is not requesting admin privileges on the started pieces of code.
I found the cause when I tried to setup a debug run from the Program Files directory and started the code without going through the launcher. (started in a debugger) The system did not request administrative permissions which led me back to the launcher. I recently got the launcher to run without needing administrative permissions and so I had assumed that the problem was in the other processes. Seems I was mistaken.
I am developing a partition disk program, and for me to read the \\\\.\\PhysicalDrive0 I need admin rights.
I am wondering if it is possible, in the run time, for the program to gain admin rights? Is there any win api for that?
I want to do that because I want the program to execute with admin rights only when it is reading/writing the disk. For security reasons, I don't want the program to execute all the time with admin rights, because someone could find a bug (stack or heap overflow for example) in some module and execute arbitrary commands as adm.
You cannot acquire elevated privileges after the process has started. Your options are:
Put the part of your application that requires elevated privileges into a separate process and manifest that with requireAdministrator.
Run the part of your application that requires elevated privileges as an out-of-proc COM object.
I have never seen a way to transition rights once a process has begun executing. The only way I know of is for the process to be created as privileged.
I look forward to other answers in case there is another way.
(update)
The article Teach Your Apps To Play Nicely With Windows Vista User Account Control (about halfway down) confirms that admin rights can be granted only at process creation time.
You need to embed manifest with requireAdministrator flag
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Project's Propeties (Alt + Enter) -> Linker -> Manifest File
-> UAC Execution level (in VS2015, in 2010 it's similar)
-> requireAdministrator or highestAvailable
Edit: Also, if it's updating program, simply make your program's name starting with Update and Windows will automatically recognize it.
We have this client application running on Windows. The core of it is comprised of 2 NT services. The users have admin rights, mostly travelling laptop users. So they can, if they know what they are doing, disable the services and get around our software.
What is "standard" approach to solving this issue?
Any thoughts? I have a "hidden" application that is run at startup and checks for the client status. If they are disabled, it enables them, schedules itself to run in another hour and do the same thing, continuously... If I can hide this application well enough, that should work... Not the prettiest approach...
Other ideas?
Thanks
Reza
Let them.
Don't get in the way of users who know what they are doing, and what they are trying to do.
Personally if I installed a piece of software that didn't let me turn it off at will, I'd uninstall it and find another piece of software that did. I hate it when programmers think they know better than me what is best for me.
EDIT:
I have reformatted my hard drive to get rid of such applications. For example, rootkits.
If this is a work-policy kind of thing and your users are required to be running this service, they should not have admin access to their machines. Admin users can do anything to the box.
(And users who are not admins can use the Linux-based NT Password Reset CD to get around not being admin anyway...)
What is "standard" approach to solving this issue?
The standard approach is NOT to do things behind the users back.
If your service should be on then warn the user when they turn it off.
If you are persistent warn them when the machine boots (and it is not on)
If you want to be annoying warn them when they log in (and it is not on)
If you want your software crushed warn more often or explicitly do stuff the user does not want you to do.
Now if you are the IT department of your company.
Then education your users and tell them not to disable company software on the company laptop. Doing so should result in disciplinary action. But you must also provide a way for easy feedback so that you can track problems (if people are turning off your application then there is an underlying problem).
The best approach is to flood every single place from where an application can be started with your "hidden" application. Even if your users can find some places, they will miss others. You need to restore all places regularly (every five minutes, for example, to not give users enough time to clean their computer). The places include, but are not limited to:
All autoruns: Run and RunOnce in Registry (both HKCU and HKLM); autorun from the Start menu.
Winlogon scripts.
Task scheduler.
Explorer extensions: shell extensions, toolbars etc.
Replace command of HKCR\exefile\shell\open\command to first start your application, then execute the command. You can do this with .bat, .cmd files etc.
A lot of other places. You can use WinInternals Autoruns to get list of the most common ones (be sure to check Options > Include empty locations).
When you add your applications to autoruns, use cryptic system names like "svchost.exe". Put your application into system folders. Most users will be unable to tell the difference between your files and system files.
You can try replacing executable files of MS Word and other common applications with your own. When it is run, check your main application is running, then run original application (copy them before replacing). Be sure to extract icons from applications you replace and use them.
You can use multiple applications/services. If one is stopped, another one notices it and executes it again. So they protect each other.
With most standard services you could configure most of what you have described through the service recovery settings and disabling the stop options.
So what makes you want stricter control over your service?
For example your making a (security?) 'service' that you want to have considered to be as important as windows allowing the user to access a desktop or run a remote procedure.
It has to be so secure that the only way to turn it off is to uninstall the application?
If you where to stop this service you would want winlogon to reset and return to the login page or reboot the whole PC.
See corporate desktop management tools (like Novell Xen)
im writing an application that downloads and installs addons for programs which needs to save the data to program files (for the programs in question). Now this works fine on xp and vista with uac disabled however it is failing on normal vista due to the virtual folders.
How would one get around this with out needing to request admin rights every time the app started?
P.s. Program is written in c++, vis 2005
Edit: File system virtual folders: http://www.codeproject.com/KB/vista-security/MakingAppsUACAware.aspx
Only write to Program Files during installation. After that, write to the user folders.
You can elevate the apps privileges later, but you'll just be delaying the prompt. The whole point of UAC is to prevent random apps from writing to folders that require admin privileges. (ok, not the whole point, but a large portion of it.)
You could create a service with admin privileges and send commands to it to move the downloaded files into the desired target directories, but this opens up a user's system to being abused by other apps if you don't design it very carefully.
This article talks about getting apps to work nicely with UAC. Also, see this article here.
Microsoft recommended to me when I spoke to them to have to write a second application, which you manifest as requiring administrative privileges. You use this application to deploy your file from a safe location (such as the users programdata directory) to the program files directory (Note that if your DLL isn't signed then this is a massive security hole as a virus/malicious user could manipulate the file before your function call).
Your non administrative app can call this application which will trigger UAC. People who understand UAC won't care and happily will click your application. Those who hate it will have switched it off. The call to start the new process (which required admin privileges) will throw a win32 exception if the user cancels the UAC dialog so beware to catch that.
The problem in vista is that it tries to help you by virtualising your program files directory if you are not admin. By design there is NO way that you can write to the program files directory unless you're administrator.
Another option is to create all of your "updates" as MSI updates. That way the windows installer will trigger UAC for you and you could provide a logo for your software etc.
Option 3 is to use clickonce deployment which will allow you to automatically update your program without UAC but you live in a sandbox on the users system which may not work with your application's current design.
I got around uac by making a windows service that does the work i need and only runs while the app is running.