public
/
website
5
0
Fork 0
Code Issues Pull Requests 3 Packages Projects Releases Wiki Activity

feat: add blog #7

Open
anton wants to merge 15 commits from feat/blog into main
pull from: feat/blog
merge into: public:main
Conversation 0 Commits 15 Files Changed 14 +6 -2
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 4abd782c11 - Show all commits

8
_posts/2024-03-28-determinism.md
View File

@ -86,7 +86,7 @@ There have been some amazing efforts by the Guix team to bootstrap GCC and the e
Mrustc however lacked support for musl libc which threw a wrench in things, but after a fair bit of experimentation we were able to patch in support musl and get it upstream. Mrustc however lacked support for musl libc which threw a wrench in things, but after a fair bit of experimentation we were able to patch in support musl and get it upstream.
The result is we now have the first deterministic musl based rust compiler bootstrapped all the way back to GCC, and you can reproduce our builds right now from any OS that can run Docker. The result is we now have the first deterministic musl based rust compiler bootstrapped all the way back to 256 bytes of assembly, and you can reproduce our builds right now from any OS that can run Docker.
## Determinism and Real World Applications ## Determinism and Real World Applications
To demonstrate how determinism can be used to prevent real world attacks in practical terms let's consider a major breach which could have been prevented. To demonstrate how determinism can be used to prevent real world attacks in practical terms let's consider a major breach which could have been prevented.
@ -94,6 +94,10 @@ To demonstrate how determinism can be used to prevent real world attacks in prac
SolarWinds experienced a major security breach in which Russian threat actors were able to compromise their infrastructure and piggyback on their software in order to distribute their malware to their entire client base. The attackers achieved this by injecting malicious code into SolarWinds products such as the Orion Platform, which was then downloaded by the end users. This seems like a very difficult thing to protect from, but there is a surprisingly simple solution. If SolarWinds leveraged deterministic builds of their software, they would have been able to detect that the binaries of the software they are delivering to their clients have been tampered. To achieve this, there are a few ways they could have gone about this, but without getting too deep into implementation details, it would have sufficed to have multiple runners in different isolated environments, or event on different cloud platforms, which would reproduce the deterministic build, and compare the resulting hashes in order to verify the binaries have not been tampered. If any of the systems built the software and got a different hash - that would be a clear signal that further investigations should be made which would have likely lead to the detection of the intruder. Without this approach, SolarWinds was completely unaware of their systems being infiltrated for months, and during this period large quantities of end user data was exfiltrated, along with their tooling. Considering that SolarWinds is a cybersecurity software and services provider, the tools stolen from them were then likely used to further develop the attacker's capabilities to avoid detection, and even weaponize them. SolarWinds experienced a major security breach in which Russian threat actors were able to compromise their infrastructure and piggyback on their software in order to distribute their malware to their entire client base. The attackers achieved this by injecting malicious code into SolarWinds products such as the Orion Platform, which was then downloaded by the end users. This seems like a very difficult thing to protect from, but there is a surprisingly simple solution. If SolarWinds leveraged deterministic builds of their software, they would have been able to detect that the binaries of the software they are delivering to their clients have been tampered. To achieve this, there are a few ways they could have gone about this, but without getting too deep into implementation details, it would have sufficed to have multiple runners in different isolated environments, or event on different cloud platforms, which would reproduce the deterministic build, and compare the resulting hashes in order to verify the binaries have not been tampered. If any of the systems built the software and got a different hash - that would be a clear signal that further investigations should be made which would have likely lead to the detection of the intruder. Without this approach, SolarWinds was completely unaware of their systems being infiltrated for months, and during this period large quantities of end user data was exfiltrated, along with their tooling. Considering that SolarWinds is a cybersecurity software and services provider, the tools stolen from them were then likely used to further develop the attacker's capabilities to avoid detection, and even weaponize them.
## Future Work ## Future Work
These initial efforts were predominately sponsored with financial and engineering time contributions from Distrust, Mysten Labs, and Turnkey who all share threat models and container-driven workflows Stagex is designed to support.
While we all have a vested interest to help maintain it, we all felt it important this project stand on its own and belong to the community and are immensely appreciative to a number of volunteers that have very quickly dived in and started making significant contributions and improvements.
As of writing this, Stagex has 100+ packages covering some of the core software you may be using regularly, all built using the deterministically built toolchain, and of course the software itself also built deterministically. Some of the packages include `rust`, `go`, `nodejs`, `python3.8`, `curl`, `bash`, `git`, `tofu` and many more. As of writing this, Stagex has 100+ packages covering some of the core software you may be using regularly, all built using the deterministically built toolchain, and of course the software itself also built deterministically. Some of the packages include `rust`, `go`, `nodejs`, `python3.8`, `curl`, `bash`, `git`, `tofu` and many more.
We would like to support building with `buildah` and `podman` for build-tooling diversity. We would also love help from the open source community to see GCC bootstrapped all the way down to x86_assembly via Mes. This may require using multiple seed distro containers to work in parallel to ensure we don’t have a single provenance source for even that layer. We would like to support building with `buildah` and `podman` for build-tooling diversity. We would also love help from the open source community to see GCC bootstrapped all the way down to x86_assembly via Mes. This may require using multiple seed distro containers to work in parallel to ensure we don’t have a single provenance source for even that layer.
@ -106,4 +110,4 @@ If you have need for high trust in your own build system, please reach out and w
* [Bootstraping rust](https://guix.gnu.org/en/blog/2018/bootstrapping-rust/) * [Bootstraping rust](https://guix.gnu.org/en/blog/2018/bootstrapping-rust/)
* [Full source bootstrappin](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/) * [Full source bootstrappin](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)
* [Running the "Reflections on Trusting Trust" Compiler](https://research.swtch.com/nih) * [Running the "Reflections on Trusting Trust" Compiler](https://research.swtch.com/nih)
* [Reflections on Trusting Trust](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf) * [Reflections on Trusting Trust](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf)