New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to launch Bundle (elevated) if access to 'WINDIR\Temp' folder is limited by SRP #5856

Open
Mefor opened this Issue Jul 29, 2018 · 5 comments

Comments

Projects
None yet
6 participants
@Mefor
Copy link

Mefor commented Jul 29, 2018

  • Which version of WiX are you building with?

WiX v3.11.1

  • Which version of Visual Studio are you building with (if any)?

Visual Studio Professional 2017, Version: 15.7.5

  • Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

WiX Toolset Visual Studio Extension version 0.9.21.62588

  • Which version of .NET are you building with?

4.5

  • If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

Windows 10 or any other version.

  • Describe the problem and the steps to reproduce it.

Unable to launch Bootstrapper Application in the following scenario:

  1. Prerequisite:
    'Software Restriction Policies' is configured to block all executables from '%WINDIR%\Temp' folder.
    local group policy editor
    It is common security practice to block viruses and malware via 'Software Restriction Policies' configuration.
  2. Steps to reproduce:
    a) Configure machine 'Software Restriction Policies' as it described in 'Prerequisite'(2) section.
    b) Run 'Bundle.exe' as 'Administrator'.
    Actual result: bundle won't be launched with the following error:
   Error 0x800704ec: Failed to launch clean room process: "C:\WINDOWS\Temp\{AB10C981-0D7D-4AA6-857F-CC37696DB4BE}\.cr\Bundle.exe" -burn.clean.room="C:\Test\Bundle.exe" -burn.filehandle.attached=652 -burn.filehandle.self=656 -log "C:\Test\bundle.log"
   Error 0x800704ec: Failed to run untrusted mode.

event viewer

  • Describe the behavior you expected and how it differed from the actual behavior.

I would expect that bundle allow to specify "clean room" location via command line parameter or engine has some kind of 'fallback' logic that will redirect "working folder" to users '%TEMP%' folder in case of any issues with '%WINDIR%\Temp' folder.

  • Additional information during workaround searching (optional).

I was trying to add 'Bundle.exe' to the 'whitelist' by adding additional 'Path Rule' to the 'Software Restriction Policies' with the help of the Path rule precedence (doc link):
When there are multiple matching path rules, the most specific matching rule takes precedence.
The following is a set of paths, from highest precedence (more specific match) to lowest precedence (more general match):

Drive:\Folder1\Folder2\FileName.Extension 
Drive:\Folder1\Folder2\*.Extension 
*.Extension 
Drive:\Folder1\Folder2\ 
Drive:\Folder1\

But, it seems like it is not possible because 'whitelist' rule for path '%WINDIR%\Temp{guid}.cr\Bundle.exe will look like '%WINDIR%\Temp{????????-????-????-????-????????????}.cr\Bundle.exe' and as it has '?' wildcards it does not override '%WINDIR%\Temp' or '%WINDIR%\Temp\ *\ *\ *.exe' rules.

Another option to 'whitelist' Bundle.exe is to add 'Hash Rule' for the unpacked ''%WINDIR%\Temp{guid}.cr\Bundle.exe', but it will require to has unpacked 'Bundle.exe' from machine that has no issues with using '%WINDIR%\Temp' folder, because file hashes of the 'real' unpacked Bundle.exe and one that is generated by 'insignia.exe' tools doesn't match.

@barnson barnson added this to the v4.0 milestone Aug 2, 2018

@barnson barnson added bug burn labels Aug 2, 2018

@aristippus

This comment has been minimized.

Copy link

aristippus commented Aug 8, 2018

Could the folder be specified as an argument, rather than being a "hardcoded" path, or even a set of hardcoded fallback paths, which seemed to be the approach you were entertaining? Organizations with these kind of controls would generally have specified allowed locations to execute from.

This link mentions using certificate rules to avoid the problem, which is fine, but you can get complaints from users about the performance hit.

https://social.technet.microsoft.com/Forums/windows/en-US/a7a6d44c-f5fe-4fab-9365-8d8b5aeb8e1c/software-restriction-policies-and-installers-that-use-temp-folders

@robmen

This comment has been minimized.

Copy link
Member

robmen commented Aug 8, 2018

Specified as an argument is an option. The discoverability on all non-automatic options is really poor and automatic options have the issue that we have to pick perfect locations. We haven't landed on the perfect solution, yet (although, I am really starting to lean towards logging that a special command-line option must be used--as you suggested originally--and be done with it).

@AlexKub

This comment has been minimized.

Copy link

AlexKub commented Oct 26, 2018

Have the same problem with antivirus settings. In my company not allow to launch any *.exe from temp directories. So i am not able to run any bootstraper project result because it create a copy in temp, launch it and get block from antivirus.
Details in this question.

@KevinMckk

This comment has been minimized.

Copy link

KevinMckk commented Nov 9, 2018

Same issue in my company, we got Software Restriction Policies so I'm unable to install Python..

Error 0x800704ec: Failed to launch clean room process: "C:\WINDOWS\Temp\{4503D88F-1BC3-44F2-93B9-481712C7D1FB}\.cr\python-3.7.1-amd64.exe" -burn.clean.room="C:\Utilisateurs\<user>\Downloads\python-3.7.1-amd64.exe" -burn.filehandle.attached=196 -burn.filehandle.self=204 
Error 0x800704ec: Failed to run untrusted mode.
@robmen

This comment has been minimized.

Copy link
Member

robmen commented Nov 9, 2018

@KevinMckk you can avoid this issue by not launching the bundle elevated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment