Rust: Hack Without Fear and Trust! (A complete development environment for Rust with VSCode inside a docker container)

Rust: Hack Without Fear and Trust!

A complete development environment for Rust with VSCode inside a docker container.

I am afraid of build.rs and procedural macros and rust development tools that can do "anything" on my system. Call me paranoid.
I want to develop Rust projects in a sandboxed/isolated environment.
I wrote my experience using Podman, Buildah, VSCode, Win10, WSL2 and the Official Rust docker image to prepare images and containers for Rust projects.
Take a look:

https://github.com/LucianoBestia/docker_rust_development

After using these containers for some time I was curious about compile performance in various environments. And I was right!
I tried cargo auto build on my project database_web_ui_on_server in different environments. I build a few times and find an average.

18s in container on WSL2 without shared volume
8s in container on WSL2 with shared volume
6s in WSL2

11s in container on Debian (dual boot) without shared volume
7s in container on Debian (dual boot) with shared volume
6s in Debian (dual boot)

Then I changed the linker to "mold" on Debian. It is 3x faster!
The "mold" linker is experimental Linux only. That's ok for me.

6.84s in container on WSL2 without shared volume
5.05s in container on WSL2 with shared volume
3.66s in WSL2

4.43s in container on Debian (dual boot) without shared volume
5.35s in container on Debian (dual boot) with shared volume
3.61s in Debian (dual boot)

That is a big difference! I decided I will develop Rust projects in Debian (dual boot) without shared volume with mold linker. The container steals a little of performance for itself, but it is not a big deal in that combination. Security is not cheap!

5 Likes

You should lobby all the crates you're interested in to switch to watt for their macro needs :slight_smile:

2 Likes

It is not only "procedural macros". The whole development system is "potentially dangerous". Probably this is valid for any development system.

I now pushed the container images to the Docker Hub. They are around 1.5 Gb.
Now is possible to try it very quickly. You just need Win10, WSL2 and VSCode.
And then later read all the grim details of how containers work.

Rust: Hack Without Fear! (sandboxed in a container)

You can try to use testcontainers. These are mainly used for integration tests (create mongo container and perform some tests), could be used to build your rust binaries in there. Not sure how to integrate this with build.rs

What other programming languages do you use?

Pretty much all development tools for all languages I have used have been able to do "anything" on my systems.

1 Like

I worked professionally 30 years with Microsoft "languages". When you buy stuff for money, you know that there exists some "quality control" behind the product.
You can trust it, you must trust it. It is closed-source.
Sure there are bugs, incredible incompetence, complete indifference, but there is no malevolent intention.
Also for third-party libraries sold for money, it is in their best interest to be trustworthy. Reputation does exist in the commercial world. No company wants to be destroyed financially because of malware in the supply chain. And they also have the money to review the code prior to publishing.
But in open-source it is impossible to work only with "reputable" developers. You will miss most of the interesting libraries. And every library is made up of tens of other libraries.
Anytime can happen that an update injects something really malevolent in an obscure non-important library. For example: "2022 - Famous npm package 'node-ipc' deletes files on developer machine."
Who to trust? What to trust?
The first line of defense should always be to develop in a sandboxed environment.
Just to mention an old-school "secure sandboxed" development environmet: javascript in the browser. It is a natural sandboxed environment. Nothing much to destroy there. The development using npm packages was secure for years because of that. But then came node.js and the world changed...

A very good question.

If you are really into software security and traceability then you work with a team in an office with no windows, no telephone lines, no network connection, no cameras allowed. Some distance away from the boundary of the site so that nobody can sniff the EM emissions from your computers or monitors etc. The results of your work are taken out of your machines and the hard drives locked in a safe every night. Your client insists on reviewing the executables compiled from your high level language. You have of course been vetted and signed an agreement that ultimately carries the death penalty for leaking any secrets.

If you think I am exaggerating, well no, I have worked in such an environment.

As for the security guarantees of Open Source vs Closed Source now a days I think it is a wash. But if you really want to take care of your destiny you need to know what is going on. Which is of course made possible with Open Source.

I do not begin to understand what you mean there.

Firstly, despite whatever sand box Javascript ran in when used in the browser it was in the prime position to intercept communication between the user and the internet at large. Even if it could not access files and such on the users machine. The dire consequences of this over the years are well known.

Meanwhile, Javascript running under node.js was never secure. There is no sand box. It runs like any other language on your machine with direct access to whatever the user has access to.

I don't think this is still accurate. These days, JavaScript is sandboxed not only from system data, but from other origins' data; the main attack vector is a phishing attack that deceives the user about the origin. Certainly, it can't "intercept communication" between the user and arbitrary servers. The primary security issue arises from browser fingerprinting, which is possibly detectable but very difficult for the browser to prevent. Developers of projects such as Tor Browser spend lots of effort making every installation look identical from the perspective of a JS script.

"These days" the box that JS runs in the browser may well be tighter. But I refer you to this: This browser-in-the-browser attack is perfect for phishing • The Register As far as I can tell all of the WEB stack was designed to "anti-secure" from the ground up. Starting from the infamous "Postel's Law" which says "Be conservative in what you do, be liberal in what you accept from others.

JS under node.js has never been secure. Typically it has as much access to a machine, the network, and whatever else, as the user running it. Doggy modules fetched from NPM can do whatever they like. Same like most other language development systems when running code form untrusted sources. Open or closed.

There is now a youtube video to show how to setup the environment and container for Rust development.

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.