PublishAot brings in Microsoft.DotNet.ILCompiler and causes AppLocker issue

[Balkoth]

Description

Publishing a project with aot tries to call findvcvarsall.bat in C:\Users\_USER_\.nuget\packages\microsoft.dotnet.ilcompiler\8.0.0\build which in turn is blocked in a corporate environment by AppLocker rules.

Reproduction Steps

• Create new console project with dotnet new console --aot
• Publish the project with dotnet publish /p:RuntimeIdentifier=win-x64 /p:SelfContained=true

Expected behavior

Project is successfully published.

Actual behavior

The build is cancelled, because at least one batch file is run from a location where, under default corporate AppLocker rules, script and exe execution is not allowed.

Regression?

No response

Known Workarounds

No response

Configuration

.NET SDK:
Version: 8.0.100
Commit: 57efcf1350
Workload version: 8.0.100-manifests.8d38d0cc

OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.100\

Other information

New workflows should be created in a way that developers can take advantage, without having administrative rights on their machines and without bothering it helpdesk and sysadmin people.

In a world where it security is a top priority it is a bad habit to expect developers in corporate environments to have excess rights on their machines just to develop software.

[Wraith2]

In a world where it security is a top priority it is a bad habit to expect developers in corporate environments to have excess rights on their machines just to develop software.

Arguably it also a bad habit to block the location that is expected to contain user specific files on that machine, doing so is what forces the user to need permissions to find somewhere else to put files so they can do their job. I suggest you contact your security department and talk to them about their inappropriate configuration.

[Balkoth]

It's people like you who make corporate environments insecure. You might not care about security, but we here do. No one here is allowed to execute scripts or executables from untrusted locations.

Allowing users to run that stuff from a userdir, where users can put anything downloaded from the web is a nightmare. Thats why AppLocker and comparable solutions exist.

[huoyaoyuan]

No one here is allowed to execute scripts or executables from untrusted locations.

What's the definition of "executable" for managed application? Is it the launcher dotnet.exe, or the dll? What if a process load an unmanaged dll, or a managed assembly?

If you are able to run roslyn analyzer installed via NuGet package, you are already violating this rule.

---

The AOT compiler is shipped via an additional package. It's not shipped with the SDK which should be set to trusted.

Shipping development-time tools with package management system isn't unusual.

[Balkoth]

I am not allowed to give any more insight to our security concept here as this information could be used by a potential attacker.

In my experience its entirely unusual that nuget packages run batch scripts, or otherwise i would have already stumbled over it.

[sylveon]

What alternative do you suggest? Trying to find a VS install from a NuGet package is gonna need to execute some code one way or another.

[Balkoth]

If a Visual Studio installation is required, then why not just include this with it in ProgramFiles? Seems like a core feature to me.

[sylveon]

Visual Studio could be installed elsewhere than in Program Files, hence the need for a findvcvarsall.bat ;)

[Balkoth]

If this is included in the vsinstalldir where you are already allowed to execute, then there will be no problem. Does not matter if its programfiles or another directory. If it's essential to find a vs install, then include such a script in the sdk.

Not providing such a seemingly essential method, sparks things like this script an a bad location. And if another package needs to find a vs install they roll their own scirpt. Now you have two scripts, each with their own bugs.

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Publishing a project with aot tries to call findvcvarsall.bat in C:\Users\_USER_\.nuget\packages\microsoft.dotnet.ilcompiler\8.0.0\build which in turn is blocked in a corporate environment by AppLocker rules.

Reproduction Steps

• Create new console project with dotnet new console --aot
• Publish the project with dotnet publish /p:RuntimeIdentifier=win-x64 /p:SelfContained=true

Expected behavior

Project is successfully published.

Actual behavior

The build is cancelled, because at least one batch file is run from a location where, under default corporate AppLocker rules, script and exe execution is not allowed.

Regression?

No response

Known Workarounds

No response

Configuration

.NET SDK:
Version: 8.0.100
Commit: 57efcf1350
Workload version: 8.0.100-manifests.8d38d0cc

OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.100\

Other information

New workflows should be created in a way that developers can take advantage, without having administrative rights on their machines and without bothering it helpdesk and sysadmin people.

In a world where it security is a top priority it is a bad habit to expect developers in corporate environments to have excess rights on their machines just to develop software.

Author:	Balkoth
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[jkotas]

You can set IlcUseEnvironmentalTools property in your .csproj file to true (this will disable invocation of findvcvarsall.bat) and setup the VS native tools build environment using alternative method that is compatible with your setup.

As others pointed out, it is very common for nuget packages to include code that executes during the build. I agree that .bat files in nuget packages may be unusual, but it is very common for nuget packages to include Powershell scripts that have same capabilities as .bat scripts and carry the same security risk.

If it's essential to find a vs install, then include such a script in the sdk.

It does not make sense to include the findvcvarsall.bat script in the sdk. findvcvarsall script is an implementation detail of the native AOT compiler package, so it should come with the package.