Most installation toolkits have the ability to launch, automatically or otherwise, external programs after installation. This is often appears in the installer via such options as "Show readme", or "Start program".


The problem is, many of these installers are poorly coded, and do not drop permissions appropriately. For example, starting the application automatically, or opening the application's homepage in the browser, often results in launching the application or browser with the installer's Administrative privileges, or a "High" UAC integrity level!

This has the potential to open up security breaches, by opening up the installed application, or a web page (and possibly browser add-ons), that are now running with elevated permissions.

(This is the reason I strongly recommend never choosing auto-launch options when installing software.)


Is there a way to prevent certain applications (such as a web browser) from ever being launched with Administrative privileges, i.e., an automatic drop-privilege based on process name?

  • 2
    I really like this question. There are products to raise rights for processes based on path, hash, etc. I'd love to see something that drops rights automatically for, say, iexplore.exe, firefox.exe, chrome.exe, etc. – Patrick Seymour Sep 9 '12 at 21:44
  • 1
    If the spawning program has admin rights, couldn't it just undo whatever you come up with and run it anyway? :) – Ƭᴇcʜιᴇ007 Sep 9 '12 at 21:56
  • 1
    I guess it could, but I would be surprised if an installer was like, "Hey, you're gonna browse our home page as administrator, buddy!" and continually enforced those permissions. I don't think I'd buy software from a company like that, provided I could find out about it. – Patrick Seymour Sep 9 '12 at 22:09

I agree, in principle, with the "RUNAS" answer.

It seems to me that what you want is for sub-process instances to be auto-restricted if they are running as admin.

There are a couple of approaches. However, they are/can be drastic and are not for the timid admin because the overhead is annoying. They will do the job, though.

Only showing Approach one unless more are requested:

For each application you want to restrict:

right click the executable and go to **PROPERTIES**
go to the **SECURITY** tab
click **ADVANCED** at the bottom
click **ADD** at the bottom
type **ADMINISTRATORS** for the name. if you have a domain then adjust appropriately
press **OK** to get the custom settings for the administrator's group
check the **DENY** checkbox next to "TRAVERSE FOLDER/ EXECUTE FILE" permission (2nd on the list)
hit OK and so-on until you've closed the properties entry for that file.

Now, members of the administrators group cannot execute that file. They can go back in and change the permissions to un-check that so they can run it, but they have to knowingly do that.

Also, since you're worried about this occurring during an installer, you would want to do the same procedure for the SYSTEM "user", which also (effectively) runs as admin as well, because this account can be used during some installations (a Windows "ADMIN" account credentials can be used to gain a SYSTEM credentials token... but this is way beyond what this question is targeting).

Here are some picture of doing this on windows 7:

enter image description here enter image description here enter image description here enter image description here enter image description here


You should be able to achieve the lower rights level with either dropmyrights or psexec.

The tricky part seems to be in making it happen automatically when an installer spawns a new instance of the application.

For that I suspect you will at least need to tweak the file associations for all relevant file types and also for URLs, prepending your existing command with the psexec command for example.

That will work as long as the installer tries to open the file/url with the associated application rather than specifying the executable to run. If the executable path is specified explicitly I guess you would need to replace the standard executable with a shim executable which runs the command you want.


One thing that is being missed here is that Internet Explorer and Windows Explorer CANNOT have their permissions elevated (unless you do a registry hack). I don't know about Firefox, Chrome, etc. but if you try to run Internet Explorer as admin, it will happily accept your credentials but will not actually elevate permissions. This is a security feature of Windows Vista and up. And besides that, the only way UAC is not in effect (unless you turned it off) is if you are logged in to the built-in administrator account. Just because something was installed with elevated permissions it doesn't mean the installer can give that program elevated permissions. Permissions are determined by the account the program was run under. The only way a program can be run with elevated permissions without you knowing it is if, for example a program starts with Windows from a registry setting, etc. If that happens it can be fixed by editing the registry.


You can use AppLocker.

I believe this is available in Windows 7 Enterprise, Ultimate and Server 2K8 and up. Not sure about Windows 8 but would assume it to be the same (Enterprise and Ultimate).

You can set up AppLocker by going into group policy:

Computer Configuration -> Windows Settings -> Security Settings -> Application Control Policies -> AppLocker -> Executable Rules.

Right click and "Create a new Rule..."

Here you can block specific executables from being run by selected users or groups. In your example, you could choose to deny execution of Internet Explorer by Administrators group.

RUNAS /trustlevel:<TrustLevel> program

/trustlevel       <Level> should be one of levels enumerated
                  in /showtrustlevels.
/showtrustlevels  displays the trust levels that can be used
                  as arguments to /trustlevel.

This requires an elevated command prompt.

Explanation / Step by Step

  1. Open the start menu and type cmd on the search bar
  2. Right click on the command prompt and select run as administrator Type:

    RUNAS /showtrustlevels
  3. Choose a trust level suitable for your application to run in, where X is the trust level you want to use and type:

    RUNAS /trustlevel:X "Application target"
  • I don't think this will work. In order to use RunAs to have the resulting browser window run with low rights, you would have to run the installer (via RunAs) with low rights. Doing so would likely cause the installer not to work. – Patrick Seymour Sep 9 '12 at 21:42
  • well if you wanted to do it that way you would change the environment variable for your browser to include the RUNAS /trustlevel command then the browser will always launch in the selected trust level, its unlikely that you would need to ever run the browser in an elevated situation... worth a thought – David McGowan Sep 10 '12 at 0:27
  • Changing the environment variable is a bit of a mission, its going to require creating a simple exe to replace the original that contains a simple call to the real executable with the RUNAS command included. like i said, bit of a mission you could just copy the address that the browser window launches with and then close and relaunch the browser and type the address in – David McGowan Sep 10 '12 at 15:58

i looked into different solutions and i can already tell you that application manifests or appcompat flags won't work (yes thats no real answer but i still wanted to share this ;))

what might be close to what you are looking for is the so called integrity level, it can be set within the filesystem (ACL) and has an effect on the token the process is holding

this article explains how you make an exe always run at "low integrity level"

another aproach would be a third party tool, like a real-time process monitor a virus scanner or application firewall would use, but i don't know of any that can be configured that way.

  • 2
    you can ignore my answer, i just tried that method and it didn't work :( – weberik Apr 7 '14 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy