When you install a program in Windows, I've always noticed you must allow it Admin (UAC elevation). However, now it can effectively do anything it wants! Unpack a service, deploy it as LOCAL SYSTEM, write in a rootkit even! All because I simply wanted to install a basic program I found on the web.

Is there a better way to handle installers out there? Where it has limited rights?

  • Follow up question that would need to be asked then: if you've succeeded in limiting an installers' privilege, how do you install something that genuinely needs higher privileges like installing a driver?
    – Steve
    Commented Jun 17, 2014 at 0:11
  • Different levels of installer permissions. A basic installer should be allowed to modify fewer things and call fewer Windows API functions as opposed to a system update installer. That way, for a random example, when you download a game from the internet, you run it without permissions to edit key system resources or call API functions to establish a Service as LOCAL system, etc. It shouldn't need that; it's a game, and a game is what you're expecting. In the current security model as I understand it, you could run a small installer and it ends up rootkit'ing your system.
    – Nathan
    Commented Jun 19, 2014 at 14:28
  • 1
    Yep, that works, but then how do you distinguish between the two elevations to say "hey this requires minimal" and "hey this requires everything"? Windows already actually does that in some places (e.g. driver installs) and people don't pay it any attention, so the net effect is people still install untrusted drivers.
    – Steve
    Commented Jun 19, 2014 at 17:25
  • I think UAC prompts should offer two levels of elevation. One that allows generic OS software installs (no driver installs or paths to create something that would run in Kernel Mode or as LOCAL SYSTEM such as a Service) and then of course the higher level which can "do anything".
    – Nathan
    Commented Jun 19, 2014 at 18:20
  • 1
    That wouldn't actually solve anything though. (Malicious) developers would still just kick off the highest elevation possible, and the user will still blindly say 'ok'. Alternatively, there are things like clickonce that do exactly as you say and install just for the user.
    – Steve
    Commented Jun 19, 2014 at 20:17

3 Answers 3


It basically boils down to trust. Most software packages are digitally signed. If they are signed by a trusted certificate you can be more sure of their identity. It's however not fool proof.

There is no real other way of knowing, if you want to be sure you will need to review every single bit of code which is not possible with Windows as it is a closed source operating system.


Interesting question. I was inspired to do a little research (I am often likewise baffled by the security policies on Windows). If I could comment I would ask if you were looking for a programmer's answer (how do I make my OWN installer stop requesting admin rights) or a user's answer (how do I safely run an installer), but since I can't I am going to give you both.

For running installers safely, I did a little searching on "sandboxing software" and found Sandboxie. Never used it, no idea if it's good, but the idea is what counts here: Sandboxie allows you to install software in a sandbox environment and run it from there, so that it stays contained and can't infect your system if it is malware. Plus it can be easily removed if you suspect that it is malicious. This doesn't really decrease its privileges, which is what you asked, but it does solve the security issue (assuming you trust your sandbox software).

For creating installers that don't require admin privileges, it remains a little bit unclear, but this post on programmer's stack exchange suggests that writing an installer to install an application on a per-user basis would allow it to run without elevated privileges. I guess when UAC was introduced with Vista, it made installers that didn't request admin privileges a little buggy, and it's just become a convention to request full admin to avoid headaches, even though the issue was supposed to be solved in Widows 7.


Check out Sandboxie.


I've been trying to figure out the same thing. So far I've found Universal Extractor Universal Extractor 2.0 (updated fork) which can extract the files from many types of installers. It's basically a frontend for many different freeware/open-source utilities (such as innounp and 7-zip) that can extract files from installers and other archive file formats. This is good for very simple installers that just extract some files into a folder. For some installer types, you can even get the script files. For instance, with Inno installers, innounp is used:

It recovers portions of the installation script (.iss file), including the registry changes and the compiled Innerfuse/RemObjects Pascal Script, if available.

For installers such as NSIS (which a lot of ransomware has been using lately), there's some limited decompilation tools to get the original script: http://nsis.sourceforge.net/Can_I_decompile_an_existing_installer

There's also some limited static-analysis programs I've found, such as pestudio (closed source, don't have enough rep to post more than 2 links), which will give you some 'indicators' of various levels of suspicion about what things the executable does. For instance, "The file modifies the registry", "The file references the Clipboard", "The file ignores Address Space Layout Randomization", etc.

As mentioned in other answers, there's some sandboxing/virtualization solutions such as sandboxie (closed source). Though I have a hard time trusting it, since it's closed source and needs to install system drivers and whatnot. And the interface and access-permission settings aren't great (it's blacklisting only, rather than block by default and whitelist, so you can't feasibly limit the programs to accessing only the directories they need to).

I'll update this if I find anything else.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .