Corporate Network: Cargo Build Blocked by Windows Security

It seems I am the only person in my organization of about 20,000 people that uses Rust. I have managed to file a request a get it packaged so that it installs (v 1.87). I have managed to define the config.toml that sets the proxy so that cargo test --lib can download packages and begin compiling.

However, during a cargo test --lib (or any type of compile) I receive this error:

Windows Security: This content is blocked.
For your protection, your administrator is not allowing you to access content from C:\Program Files\my-project\target\release\build\paste-e567683698fcaa5\build-script-build.exe

I have admin rights for my PC which means that I can unblock this, but this is too late in the process, the next build process will create a different random name for the folder and the file will again be blocked, so the process can never complete for all the many sub folders that generate these files.

My organization's IT support are, in some ways, trying to help, but have not encountered this issue or Rust before so are coming up empty at the moment. They also commented that: "yeah, I've looked into how Rust works for these scenarios. But it seems quite a bit of an oversight from Rust Vendor, since security standards are really strict nowadays."

Anyone can suggest any ways forwards?

Is there any reason why "my-project" is located in the "C:\Program Files" folder, and not in your home directory under "C:\Users\ ..." ?

4 Likes

WSL and cross-building to Windows might be an option for you. Creating binaries during the build is a fairly normal feature of build systems.

It was located in a Users\myuser\ folder first but there was a suggestion to try and move it to Program Files with admin rights. It didnt make a difference.

I discovered that if you goto Windows defender log you can discover exactly what these issues are.

This was caused by a strict Attack Surface Policy.

I used the following page and discovered that my organisation had whitelisted some wildcard folders that I could move my project too (with admin rights). Possibly I could add my own Attack Surface Reduction policies but that felt a little less ethical or abusing the admin rights policy.

Then all files can compile.

My organization's IT support are, in some ways, trying to help, but have not encountered this issue or Rust before so are coming up empty at the moment.

Rust builds executables and runs them, so that may be a bit uncommon, but many other languages do similar arbitrary code execution at build time, just through script interpreters or JIT runtimes instead of compiled binaries. NPM has pre/postinstall scripts, python has/had setup.py and similar, gradle project definitions (gradle files) are scripts etc.

So how does your company deal with arbitrary code execution on developer machines? If they have good reason to forbid it (e.g. prior targeted attacks, high value assets, ...) then you need to work with them to find a secure build process. E.g. vendoring and auditing the scripts, using isolated build containers or avoiding libraries with build scripts.

If they just are applying a security-maximalist policy meant for general office work without having spent much thought about software devs... well, then work with them to on some alternatives. Maybe they can put you on a separate network. Or you can make all your credentials backed by a hardware security token so that if your machine gets compromised doesn't have many usable credentials they can exfiltrate (though you'd still have to worry about company data your machine has access to).

If they have the risk tolerance to just allow bypassing their standard measures without further mitigations then yeah, adding your project build dirs to an exception list isn't unusual. Just inform them of what you did.

4 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.