Compare commits
No commits in common. "master" and "feat/add-openpgp-workshop" have entirely different histories.
master
...
feat/add-o
|
|
@ -1,457 +0,0 @@
|
||||||
---
|
|
||||||
_class: lead
|
|
||||||
paginate: true
|
|
||||||
backgroundColor: #fff
|
|
||||||
---
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
|
||||||
|
|
||||||
Hey my name is Lance, a co-founder of Distrust, a security auditing and engineering company that specializes in working with high risk organizations that can't afford to trust any single computer or person. I also founded #!, a security, privacy, and digital sovereginity focused digital hackerspace built around classic public access linux systems. I also have architected and built a lot of software you have may have seen or used at one point or another over the years. I am not proud of most of it. I only do open source things now.
|
|
||||||
|
|
||||||
You have possibly seen articles of some of my various dumb publicity stunts to try to get people to care about privacy rights and supply chain security. Sorry. The japanese robot hotel one was funny though.
|
|
||||||
|
|
||||||
I now work with a team of people smarter than me at Distrust and the wider open source community and we are working on actually -solving- supply chain trust problems, because me complaining about them for years didn't work. One of those projects we are talking about today, Stagex!
|
|
||||||
|
|
||||||
Also, many have heard me preach the 10/20/30 rules of presentations.
|
|
||||||
|
|
||||||
Let's break all those rules real quick as we have a bunch of slides I want to get through fast because giving presentations terrifies me, which is why I dropped out of school.
|
|
||||||
|
|
||||||
You can read the markdown file I generated these slides from later.
|
|
||||||
|
|
||||||
I am in this for the interesting part. Questions, discussion, and debate!
|
|
||||||
|
|
||||||
Here goes.
|
|
||||||
|
|
||||||
A lot of us build software responsible for protecting immense amount of financal value, important secrets, or even human lives.
|
|
||||||
|
|
||||||
When you really boil it all down, there is almost always at least one person you can point at with the power to tamper with the software that builds your software without anyone noticing.
|
|
||||||
|
|
||||||
That person is often loves their family, likes money, or does not have good opsec. Or maybe they just let a personal email domain expire which allowed any rando to take over their release responsibilities. Several thousand supply chain critical domans are up for grabs right now by the way. I bought a few. It's easy.
|
|
||||||
|
|
||||||
In this example here, imagine someone simply placed libfakerand (shameless to my co-founder Anton) in a popular container image. After all the world runs on containers today, and almost none of them are signed or even gated with hardware multi factor auth.
|
|
||||||
|
|
||||||
|
|
||||||
Let's TLDR the problem.
|
|
||||||
|
|
||||||
|
|
||||||
And now let's TLDR the solution we landed on, with some buzzword bingo
|
|
||||||
|
|
||||||
Don't worry, the rest of the slides are mostly just me breaking this down.
|
|
||||||
|
|
||||||
So going back to what I was saying earlier, people use containers today for basically everything.
|
|
||||||
|
|
||||||
Most distros started before the OCI standard was a thing, which is why most Linux distros approach to containers feels like a hastily retrofitted bastardization that walks back critical security choices in the name of broad adoption above all else.
|
|
||||||
|
|
||||||
We asked ourselves what would happen if we just used the OCI standard all the way down from the start. Could we just use that spec basically as-is with some creative patterns, and no package manager at all, and still end up with something declarative, easy to maintain, and reproducible, with a lot of properties we like about Nix and Guix for downstream reproducibility in end user projects?
|
|
||||||
|
|
||||||
It sounds like a drunk idea the spec authors never considered, but with the right patterns it works great.
|
|
||||||
|
|
||||||
Here is our actual BC package, which is a pretty typical example. Its pretty much just linux from scratch in containers.
|
|
||||||
|
|
||||||
Note that we force the hash-locking on the dependencies at build-time to be whatever is in the same git tree
|
|
||||||
|
|
||||||
But now for a harder problem. What toolchain do we trust enough to build our toolchain that requires trusting no single party?
|
|
||||||
|
|
||||||
We didn't have an answer until we stumbled upon the Bootstrappable Builds project. Build everything from zero and get the same results no matter what host OS you are using. They had only gotten it all working a month before we started stagex. Perfect timing.
|
|
||||||
|
|
||||||
This concept is called full source bootstrapping.
|
|
||||||
|
|
||||||
There are plenty of talks about this, so I'll just TL;DR the strategy we landed on.
|
|
||||||
|
|
||||||
We start with a tiny self hosting program written in hex0, that is just enough code to build itself, and a slightly more sophisticated version of itself, hex1, and so on, until we have a basic shell called Kaem. This set of binaries is called stage0, and often referred to as seed binaries, which everything else grows from.
|
|
||||||
|
|
||||||
In stage1 we use the live bootstrap project to speed run compiling snapshots of 150 stages of open software toolchains from 1970s era to modern x86 GCC.
|
|
||||||
|
|
||||||
In stage2 we build a cross compiler bridging from x86 to our target architecture
|
|
||||||
|
|
||||||
In stage3 we build a standalone native nano linux toolchain with busybox for our target architecture
|
|
||||||
|
|
||||||
With several people doing this and getting the same bit for bit identical results and signing them, we finally have a reproducible base image we can trust to build everything else deterministically.
|
|
||||||
|
|
||||||
-now- we are in really good shape to build almost any software reproducibly.
|
|
||||||
|
|
||||||
Reproducibility itself is probably the least new of anything here, but we do have a very strict definition.
|
|
||||||
|
|
||||||
Not having to support desktop users helps a lot
|
|
||||||
|
|
||||||
But for us reproducibilty is mostly about accountability and tamper evidence. We don't want you to trust some random build server realy reproduced something. You should have a way to verify multiple independent humans did it, and ideally do it in a way that uses standards so it is possible to set your own trust thresholds before a package of ours can run in your environment.
|
|
||||||
|
|
||||||
Most distros opt for a centralized trust scope with the whole world trusting one release engineer, or maybe worse, a distributed model where every maintainer can do whatever they want with their own packages with no oversight.
|
|
||||||
|
|
||||||
We wanted decentralized trust, where we assume at least one member of the team is compromised or malicious at all times.
|
|
||||||
|
|
||||||
Thankfully the OCI spec has a policy system for multi-signing images that seemingly no one uses. Lets actually use it!
|
|
||||||
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<style>
|
|
||||||
/* Changed in Marp 4.0.0. Re-center. */
|
|
||||||
section.lead {
|
|
||||||
display: flex;
|
|
||||||
}
|
|
||||||
|
|
||||||
div.two-columns {
|
|
||||||
column-count: 2;
|
|
||||||
}
|
|
||||||
</style>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
# Easier supply chain security
|
|
||||||
|
|
||||||
A container-native, full-source-bootstrapped, reproducible, and multi-signed toolchain to build all the things.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Do you know who built your base image?
|
|
||||||
|
|
||||||
```dockerfile
|
|
||||||
FROM trusted/distro
|
|
||||||
RUN pkg install openssl
|
|
||||||
ENTRYPOINT ["/usr/bin/openssl"]
|
|
||||||
CMD ["rand", "-hex", "12"]
|
|
||||||
```
|
|
||||||
|
|
||||||
<hr />
|
|
||||||
|
|
||||||
<div class="two-columns">
|
|
||||||
|
|
||||||
<div>
|
|
||||||
|
|
||||||
```sh
|
|
||||||
> docker build -t local/randtest -f Containerfile .
|
|
||||||
|
|
||||||
> docker run local/randtest
|
|
||||||
|
|
||||||
2a2a2a2a2a2a2a2a2a2a2a2a
|
|
||||||
|
|
||||||
> docker run local/randtest
|
|
||||||
|
|
||||||
2a2a2a2a2a2a2a2a2a2a2a2a
|
|
||||||
```
|
|
||||||
|
|
||||||
Woops, someone included libfakerand!
|
|
||||||
</div>
|
|
||||||
|
|
||||||
<div>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
</div>
|
|
||||||
|
|
||||||
</div>
|
|
||||||
|
|
||||||
<!-- Include link to repo -->
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Problem Statement
|
|
||||||
|
|
||||||
## Build software without expecting users to trust any single human or computer.
|
|
||||||
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
|
|
||||||
We really didn't want to make yet another Linux distro.
|
|
||||||
|
|
||||||
Sadly, nothing we evaluated fit our threat model.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
Let's first break down the buzzword bingo:
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
|
|
||||||
## Stagex is a container-native, full-source-bootstrapped, reproducible, and multi-signed toolchain to build all the things.
|
|
||||||
|
|
||||||
---
|
|
||||||
# Container-native
|
|
||||||
|
|
||||||
- Most sysadmins today do everything in containers
|
|
||||||
- Most release engineers today build everything in containers
|
|
||||||
- OCI container spec solves the problems of most linux package managers
|
|
||||||
- OCI syntax allows for very succinct and simple package definitions
|
|
||||||
- OCI has many competing implementations, and this is a good thing!
|
|
||||||
- OCI has official support for multiple signatures, and signing policies
|
|
||||||
- Every stagex package is just an OCI layer, which can be hash locked
|
|
||||||
|
|
||||||
---
|
|
||||||
### Our actual BC "package" is just OCI layers all the way down
|
|
||||||
|
|
||||||
```dockerfile
|
|
||||||
FROM scratch AS build
|
|
||||||
ARG VERSION
|
|
||||||
COPY --from=stagex/core-busybox . /
|
|
||||||
COPY --from=stagex/core-gcc . /
|
|
||||||
COPY --from=stagex/core-binutils . /
|
|
||||||
COPY --from=stagex/core-make . /
|
|
||||||
COPY --from=stagex/core-musl . /
|
|
||||||
COPY --from=fetch . .
|
|
||||||
RUN tar -xf sed-${VERSION}.tar.xz
|
|
||||||
WORKDIR /sed-${VERSION}
|
|
||||||
RUN --network=none <<-EOF
|
|
||||||
set -eux
|
|
||||||
./configure --prefix=/usr
|
|
||||||
make -j "$(nproc)"
|
|
||||||
make DESTDIR=/rootfs install
|
|
||||||
EOF
|
|
||||||
FROM stagex/core-filesystem AS package
|
|
||||||
COPY --from=build /rootfs/ /
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
# Full source bootstrapped
|
|
||||||
|
|
||||||
TL;DR: Solve Ken Thompsan's Trusting Trust problem:
|
|
||||||
|
|
||||||
- Stage 0: Bootstrap primitive binaries from 256 bytes of hex0
|
|
||||||
- Stage 1: Bootstrap all the way up to x86 GCC
|
|
||||||
- Stage 2: Build GCC cross compiler toolchain
|
|
||||||
- Stage 3: Building a native hosted GCC toolchain
|
|
||||||
- Stage X: Build whatever you want
|
|
||||||
|
|
||||||
|
|
||||||
Only possible because of heroic work by the Bootstrappable Builds team!
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Stage0: Build bootstrap seeds with self hosting hex0 "compiler"
|
|
||||||
|
|
||||||
```hex
|
|
||||||
0000000 457f 464c 0101 0301 0000 0000 0000 0000
|
|
||||||
0000010 0002 0003 0001 0000 804c 0804 002c 0000
|
|
||||||
0000020 0000 0000 0000 0000 0034 0020 0001 0000
|
|
||||||
0000030 0000 0000 8000 0804 8000 0804 00b5 0000
|
|
||||||
0000040 00b5 0000 0001 0000 0001 0000 5b58 315b
|
|
||||||
0000050 6ac9 5805 cd99 5b80 6650 41b9 6602 c0ba
|
|
||||||
0000060 6a01 5805 80cd 4299 3197 89ed 4ed6 895b
|
|
||||||
0000070 6ae1 5803 80cd 8553 75c0 4005 db31 80cd
|
|
||||||
0000080 018a 0a3c e574 f685 e475 233c df74 3b3c
|
|
||||||
0000090 db74 302c 0a2c 0872 072c df24 073c ce73
|
|
||||||
00000a0 e5c1 0404 010a f7c5 7cdf 89c3 8929 b0fb
|
|
||||||
00000b0 cd04 eb80 00b4
|
|
||||||
00000b5
|
|
||||||
```
|
|
||||||
|
|
||||||
It makes more sense with comments:
|
|
||||||
https://github.com/oriansj/stage0-posix-x86/blob/master/hex0_x86.hex0
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Stage1: Bootstrap up to x86 gcc toolchain from bootstrap seeds
|
|
||||||
|
|
||||||
It is basically building up from the 1970s all over again
|
|
||||||
|
|
||||||
- Step 1: hex0
|
|
||||||
- Step 9: M0 C (cc_x86)
|
|
||||||
- Step 19: scheme (GNU Mes)
|
|
||||||
- Step 20: ~C99 C (Tinycc)
|
|
||||||
- Step 56: perl 5x
|
|
||||||
- Step 83: gcc 4x
|
|
||||||
- Step 148: python 2x
|
|
||||||
- Step 158: gcc 13x (still x86)
|
|
||||||
|
|
||||||
Full steps: https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Stage2: Pivot from x86 -> $TARGET cross toolchain
|
|
||||||
|
|
||||||
It is not that exciting.
|
|
||||||
|
|
||||||
- Step 1: Build cross binutils
|
|
||||||
- Step 2: Build minimal cross gcc (without libgcc)
|
|
||||||
- Step 3: Build libgcc against musl headers
|
|
||||||
- Step 4: Build musl
|
|
||||||
- Step 5: Build rest of gcc
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Stage3: Build native $TARGET toolchain
|
|
||||||
|
|
||||||
Also not that exciting.
|
|
||||||
|
|
||||||
- Step 1: Build musl
|
|
||||||
- Step 2: Build binutils
|
|
||||||
- Step 3: Build make
|
|
||||||
- Step 4: Build gcc
|
|
||||||
- Step 5: Build busybox
|
|
||||||
|
|
||||||
This covers "full source bootstrapped"
|
|
||||||
|
|
||||||
Now we can talk about what we mean by reproducible.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Reproducible
|
|
||||||
|
|
||||||
- 100% reproducible with no compromises
|
|
||||||
- Must be easy and doable at any time: Clone our repo and run "make"
|
|
||||||
- We disagree with the metrics most distros use for reproducibility
|
|
||||||
- Requiring a non-reproducible binary to acheive reproduction, is cheating
|
|
||||||
- We build -everything- from 0. Rust, random firmware blobs in qemu. Everything.
|
|
||||||
|
|
||||||
<br />
|
|
||||||
<br />
|
|
||||||
|
|
||||||
( In fairness, ignoring desktop use cases has made these goals a -lot- easier.)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Multi-signed
|
|
||||||
|
|
||||||
* Centralized Trust is dangerous
|
|
||||||
* Distributed Trust is maybe even more dangerous
|
|
||||||
* We went with Decentralized trust: trust a quorum, not any individual.
|
|
||||||
* Sign every commit with a hardware token
|
|
||||||
* Sign every review with a hardware token
|
|
||||||
* Sign every reproductions on diverse systems with a hardware token
|
|
||||||
* Reproduce and submit your own signatures for the whole tree at any time!
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!--
|
|
||||||
flowchart TB
|
|
||||||
Build1[Build] --\> Reproduce1[Reproduce]
|
|
||||||
Build2[Build] --\> Reproduce2[Reproduce]
|
|
||||||
Reproduce1 --\> Sign1[Sign]
|
|
||||||
Reproduce2 --\> Sign2[Sign]
|
|
||||||
Sign1 --\> Release
|
|
||||||
Sign2 --\> Release
|
|
||||||
|
|
||||||
{
|
|
||||||
"theme": "light",
|
|
||||||
"themeCSS": ".label foreignObject { overflow: visible; }"
|
|
||||||
}
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Decentralized Trust
|
|
||||||
|
|
||||||
Multiple maintainers can each sign individual images, so OCI runtime policies
|
|
||||||
can enforce _multiple_ signatures by maintainers to ensure no individual
|
|
||||||
maintainer could have tampered with an image.
|
|
||||||
|
|
||||||
[](https://mermaid.ink/svg/pako:eNpdklFrgzAQx79KuGdbV91s62DQpmNPZbDube4hJqdmRFNi7Cjid1-sa7EGAvn_f3c5LpcWuBYIMWRK__KCGUs-d0lF3NpvvvZMVtZtNGTzTWazF_Km_-F2DLcTSMeQTuBmkJReb5poOtFD_EdT27uEkUFvBnhQoimZFK6ltscJ2AJLTCB2RyXzwibgjQA9HAY2VyxFRTJtUObVe_qD3JKW6BOa_m1icpK1TBU-ky6BpOpcKdZYfThXHGJrGvTA6CYvIM6Yqp1qjoJZ3EmWG1ZeQwbzVUirzS1SaSbQyRbs-dgPI5eXVriuMpn3fmOUswtrj3Xs-z2e59IWTTrnuvRrKfrJFad15EdBtGJBiNEyZE9hKHi6WK-y4HGRieXDImDQdR7gpf5-mPzlA3R_HuyhBw)
|
|
||||||
|
|
||||||
<!--
|
|
||||||
flowchart TD
|
|
||||||
MA[Maintainer A] --\> Go
|
|
||||||
MB[Maintainer B] --\> Go
|
|
||||||
MC[Maintainer C] --\> Go
|
|
||||||
MA --\> GCC
|
|
||||||
MB --\> GCC
|
|
||||||
MC --\> GCC
|
|
||||||
MA --\> Rust
|
|
||||||
MB --\> Rust
|
|
||||||
MC --\> Rust
|
|
||||||
|
|
||||||
{
|
|
||||||
"theme": "light",
|
|
||||||
"themeCSS": ".label foreignObject { overflow: visible; }"
|
|
||||||
}
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
| Distro | Trust Model | OCI | Packaging | Bootstrapped | Reproducible |
|
|
||||||
|-----------|---------------|-----------|--------------|--------------|--------------|
|
|
||||||
| Stagex | Decentralized | Native | Declarative | Yes | Yes |
|
|
||||||
| Guix | Distributed | Exported | Declarative | Yes | Mostly |
|
|
||||||
| Debian | Distributed | Published | Imperative | No | Mostly |
|
|
||||||
| Arch | Distributed | Published | Imperative | No | Mostly |
|
|
||||||
| Nix | Centralized | Exported | Declarative | Partial | Mostly |
|
|
||||||
| Yocto | Centralized | Exported | Source Only | No | Mostly |
|
|
||||||
| Buildroot | Centralized | Exported | Source Only | No | Mostly |
|
|
||||||
| Alpine | Centralized | Published | Imperative | No | No |
|
|
||||||
| Fedora | Centralized | Published | Imperative | No | No |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# TL;DR: Give everyone a shorter path to better supply chain security
|
|
||||||
<br />
|
|
||||||
|
|
||||||
### A reproducible full source bootstrapped Containerfile for a rust project:
|
|
||||||
<br />
|
|
||||||
|
|
||||||
```dockerfile
|
|
||||||
ARG RUST_VERSION
|
|
||||||
FROM stagex/pallet-rust@${RUST_VERSION} AS build
|
|
||||||
ADD src/ .
|
|
||||||
ENV RUSTFLAGS='-C target-feature=+crt-static'
|
|
||||||
RUN cargo build --release --target-dir .
|
|
||||||
|
|
||||||
FROM stagex/filesystem AS package
|
|
||||||
COPY --from=build hello /usr/bin/hello
|
|
||||||
CMD ["/usr/bin/hello"]
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Common toolchain dependencies
|
|
||||||
|
|
||||||
StageX comes with developer-loved tooling and languages, such as:
|
|
||||||
|
|
||||||
- `rust`
|
|
||||||
- `go`
|
|
||||||
- `python`
|
|
||||||
- `curl`
|
|
||||||
- `git`
|
|
||||||
|
|
||||||
If you are interested in additionally software being added feel free to open a
|
|
||||||
PR or let us know what you would like to see added.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Key Takeaways
|
|
||||||
|
|
||||||
* StageX packages the software you're already using, securely.
|
|
||||||
* By leveraging OCI (Docker, podman, etc), we avoid mixing package managers and build contexts.
|
|
||||||
* Your software, at every point in the bootstrapped toolchain, can all be built
|
|
||||||
deterministically.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# What's Next?
|
|
||||||
|
|
||||||
* Packaging more software and updating existing software faster
|
|
||||||
* Adding additional container runtimes like Podman and Kaniko
|
|
||||||
* Adding additional chip architecture support such as ARM and RISC-V
|
|
||||||
* Crosschains: Cross compiler packages so you can target any arch from your native arch
|
|
||||||
* Mirrors: Much more maintainable source/mirror management in review
|
|
||||||
* Pallets: sets of deps to be imported/locked with one line
|
|
||||||
* Boxes: Easily output stagex builds as bootable ISO images, firmware, packages for other distros, etc
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Links
|
|
||||||
|
|
||||||
**Matrix Chat**: #stagex:matrix.org
|
|
||||||
|
|
||||||
**Git Repo**: https://codeberg.org/stagex/stagex
|
|
||||||
|
|
||||||
**Slides**: https://git.distrust.co/public/presentations
|
|
||||||
|
|
||||||
**ReprOS**: https://codeberg.org/stagex/repros
|
|
||||||
|
|
||||||
**AirgapOS**: https://git.distrust.co/public/airgap
|
|
||||||
|
|
||||||
**EnclaveOS**: https://git.distrust.co/public/enclaveos
|
|
||||||
|
|
||||||
**Keyfork**: https://git.distrust.co/public/keyfork
|
|
||||||
|
|
||||||
Big thank you to sponsors who have supported the development of this project:
|
|
||||||
|
|
||||||
**Turnkey, Distrust, Mysten Labs**
|
|
||||||
|
|
@ -1,49 +0,0 @@
|
||||||
{"version": 2, "width": 63, "height": 15, "timestamp": 1729797434, "env": {"SHELL": "/usr/bin/zsh", "TERM": "screen-256color"}}
|
|
||||||
[0.090248, "o", "Sending build context to Docker daemon 557.1kB\r"]
|
|
||||||
[0.093028, "o", "Sending build context to Docker daemon 1.037MB\r\r\r\n"]
|
|
||||||
[0.100052, "o", "Step 1/27 : FROM scratch AS libfakerand\r\n ---> \r\nStep 2/27 : COPY --from=stagex/busybox . /\r\n"]
|
|
||||||
[0.326734, "o", " ---> edd79937efa6\r\nStep 3/27 : COPY --from=stagex/rust . /\r\n"]
|
|
||||||
[3.478221, "o", " ---> 35b5a434bf39\r\nStep 4/27 : COPY --from=stagex/musl . /\r\n"]
|
|
||||||
[4.308798, "o", " ---> 8d65fe22c193\r\nStep 5/27 : COPY --from=stagex/gcc . /\r\n"]
|
|
||||||
[7.231311, "o", " ---> f46a59e4564b\r\nStep 6/27 : COPY --from=stagex/llvm . /\r\n"]
|
|
||||||
[15.022258, "o", " ---> d5f07172a03e\r\nStep 7/27 : COPY --from=stagex/binutils . /\r\n"]
|
|
||||||
[17.816179, "o", " ---> 1446a550e47e\r\nStep 8/27 : COPY --from=stagex/libunwind . /\r\n"]
|
|
||||||
[18.026051, "o", " ---> b3a28fc5dea5\r\nStep 9/27 : COPY --from=stagex/git . /\r\n"]
|
|
||||||
[19.450747, "o", " ---> 7c84e6add4fd\r\nStep 10/27 : COPY --from=stagex/openssl . /\r\n"]
|
|
||||||
[24.905698, "o", " ---> 05e936ce8fcc\r\nStep 11/27 : COPY --from=stagex/zlib . /\r\n"]
|
|
||||||
[25.316081, "o", " ---> bfc560e9b56c\r\nStep 12/27 : COPY --from=stagex/curl . /\r\n"]
|
|
||||||
[25.711448, "o", " ---> ba0ba47e7082\r\nStep 13/27 : COPY --from=stagex/ca-certificates . /\r\n"]
|
|
||||||
[25.948894, "o", " ---> 3e514bf61f14\r\nStep 14/27 : RUN git clone https://git.distrust.co/public/libfakerand /libfakerand\r\n"]
|
|
||||||
[25.996504, "o", " ---> Running in 64b239021be1\r\n"]
|
|
||||||
[26.25651, "o", "\u001b[91mCloning into '/libfakerand'...\r\n\u001b[0m"]
|
|
||||||
[27.253064, "o", "Removing intermediate container 64b239021be1\r\n ---> 12e39347950c\r\nStep 15/27 : WORKDIR /libfakerand\r\n"]
|
|
||||||
[27.306275, "o", " ---> Running in 81ef320df04c\r\n"]
|
|
||||||
[27.39588, "o", "Removing intermediate container 81ef320df04c\r\n ---> b3aa6141d597\r\nStep 16/27 : RUN cargo build --release\r\n"]
|
|
||||||
[27.42789, "o", " ---> Running in efc23d84c13e\r\n"]
|
|
||||||
[27.865516, "o", "\u001b[91m Updating crates.io index\r\n\u001b[0m"]
|
|
||||||
[28.438381, "o", "\u001b[91m Downloading crates ...\r\n\u001b[0m"]
|
|
||||||
[29.195025, "o", "\u001b[91m Downloaded libc v0.2.155\r\n\u001b[0m"]
|
|
||||||
[29.297817, "o", "\u001b[91m Compiling libc v0.2.155\r\n\u001b[0m"]
|
|
||||||
[30.795761, "o", "\u001b[91m Compiling fakerand v0.1.0 (/libfakerand)\r\n\u001b[0m"]
|
|
||||||
[31.181977, "o", "\u001b[91m Finished `release` profile [optimized] target(s) in 3.48s\r\n\u001b[0m"]
|
|
||||||
[31.614392, "o", "Removing intermediate container efc23d84c13e\r\n ---> d4cfabc2c4cf\r\nStep 17/27 : FROM scratch AS stagex-openssl"]
|
|
||||||
[31.614434, "o", "\r\n ---> \r\nStep 18/27 : COPY --from=stagex/libunwind . /"]
|
|
||||||
[31.614473, "o", "\r\n"]
|
|
||||||
[31.620488, "o", " ---> Using cache\r\n"]
|
|
||||||
[31.633181, "o", " ---> 3895b7cdfa39\r\nStep 19/27 : COPY --from=stagex/gcc . /\r\n"]
|
|
||||||
[31.634595, "o", " ---> Using cache\r\n"]
|
|
||||||
[31.65996, "o", " ---> 6304acd44b17\r\nStep 20/27 : COPY --from=stagex/openssl . /\r\n"]
|
|
||||||
[31.661799, "o", " ---> Using cache\r\n"]
|
|
||||||
[31.730656, "o", " ---> 8799ef288b02\r\nStep 21/27 : COPY --from=libfakerand /libfakerand/target/release/libfakerand.so /usr/lib/libfakerand.so\r\n"]
|
|
||||||
[31.736582, "o", " ---> Using cache\r\n"]
|
|
||||||
[31.742629, "o", " ---> ba82f79e88a0\r\nStep 22/27 : ENV LD_PRELOAD=/usr/lib/libfakerand.so\r\n"]
|
|
||||||
[31.742876, "o", " ---> Using cache\r\n ---> 3e25a2531027\r\nStep 23/27 : ENV FAKERAND=42\r\n"]
|
|
||||||
[31.74303, "o", " ---> Using cache\r\n ---> e1eef54546c7\r\n"]
|
|
||||||
[31.743096, "o", "Step 24/27 : FROM stagex-openssl\r\n"]
|
|
||||||
[31.743904, "o", " ---> e1eef54546c7\r\nStep 25/27 : COPY --from=stagex/musl . /\r\n"]
|
|
||||||
[31.746176, "o", " ---> Using cache\r\n"]
|
|
||||||
[31.753847, "o", " ---> d1b29448f0fe\r\nStep 26/27 : ENTRYPOINT [\"/usr/bin/openssl\"]\r\n"]
|
|
||||||
[31.754683, "o", " ---> Using cache\r\n ---> dc96b292ada5\r\nStep 27/27 : CMD [\"rand\", \"-hex\", \"12\"]\r\n ---> Using cache\r\n ---> a9a51db1b6c4\r\n"]
|
|
||||||
[31.755884, "o", "Successfully built a9a51db1b6c4\r\n"]
|
|
||||||
[31.759232, "o", "Successfully tagged stagex/openssl:latest\r\n"]
|
|
||||||
[32.116324, "o", "2a2a2a2a2a2a2a2a2a2a2a2a\r\n"]
|
|
||||||
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 329 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 117 KiB |
|
|
@ -1,480 +0,0 @@
|
||||||
---
|
|
||||||
_class: lead
|
|
||||||
paginate: true
|
|
||||||
backgroundColor: #fff
|
|
||||||
---
|
|
||||||
|
|
||||||
<style>
|
|
||||||
/* Changed in Marp 4.0.0. Re-center. */
|
|
||||||
section.lead {
|
|
||||||
display: flex;
|
|
||||||
}
|
|
||||||
|
|
||||||
div.two-columns {
|
|
||||||
column-count: 2;
|
|
||||||
}
|
|
||||||
</style>
|
|
||||||
|
|
||||||
# Expanding (Dis)Trust
|
|
||||||
|
|
||||||
How can we prove that our software has not been tampered during build time?
|
|
||||||
|
|
||||||
* Binary - software that's in a format computers can work with
|
|
||||||
* Compiler - builds software into binaries
|
|
||||||
* Hashing - takes a data set and produces a fixed length string
|
|
||||||
* 8a1aaf746ada2a80fab03a58c91575ffe82885ac "banana"
|
|
||||||
* 9144b7b25e83a315de79e7a527f5631f9d4dacf2 "banan"
|
|
||||||
|
|
||||||
<!--
|
|
||||||
|
|
||||||
* How do we do this today? We don't really have great tools to do this. There is monitoring, we can do static analysis etc., but these are not a direct way of
|
|
||||||
ensuring our software wasn't tampered, but rather monitor the environment, and hope we catch things using static analysis etc.
|
|
||||||
|
|
||||||
* This talk is about how we can practically verify integrity of software
|
|
||||||
|
|
||||||
-->
|
|
||||||
---
|
|
||||||
|
|
||||||
# Anton Livaja
|
|
||||||
|
|
||||||
Co-Founder & Security Engineer at Distrust (https://distrust.co)
|
|
||||||
|
|
||||||
* Firm specializing in high assurance security consulting and engineering.
|
|
||||||
|
|
||||||
* Mission: to improve the security, privacy and freedom of as many people as
|
|
||||||
possible through working on fundamental security problems and creating open
|
|
||||||
source solutions.
|
|
||||||
|
|
||||||
* Clients: electrical grid operators, healthcare providers, fin-tech companies
|
|
||||||
and more.
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* We specialize in supply chain security, operating system engineering, infrastructure hardening, and applied cryptography
|
|
||||||
|
|
||||||
* We exclusively use and write open source software
|
|
||||||
|
|
||||||
* Introduce some problems teams maybe weren't even thinking about
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Ken Thompson's Reflections on Trusting Trust
|
|
||||||
|
|
||||||
> **[The moral is obvious. You can't trust code that you did not totally create
|
|
||||||
yourself**. (Especially code from companies that employ people like me.) No
|
|
||||||
amount of source-level verification or scrutiny will protect you from using
|
|
||||||
untrusted code...]
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* Ken Thompson is a computer scientist from Bell Labs, read a
|
|
||||||
Air Force paper where he got this idea
|
|
||||||
|
|
||||||
* Even if you review your source code and verify it's secure, that's not enough, as the compiler can still modify code
|
|
||||||
|
|
||||||
* How can you trust a compiler... but also how can you trust all the software downstream from the compiler, that's built by it. And again, how do we easily check if the compiler, or some other aspect of the environment injected malicious software (guest software)?
|
|
||||||
|
|
||||||
* This is an unexplored attack surface area I will do my best to contextualize
|
|
||||||
it and give you a good intuition about it
|
|
||||||
|
|
||||||
* I won't open the can of worms on whether it's better to use open source
|
|
||||||
software in the context of security, but I'm firmly in the camp of don't trust,
|
|
||||||
verify
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* One of the most significant breaches in recent history - Orion software platform - a monitoring tool to help orgs manage their infra including networks, servers, applications, dbs etc.
|
|
||||||
* 1000s of enterprise and government customers had their systems completely exposed
|
|
||||||
* This company is one of the GO TO companies for cybersecurity solutions
|
|
||||||
* The other thing that happened is that the APT stole cybertooling and weaponized it and used to improve their evasive abilities
|
|
||||||
* This means that IP, government secrets etc could have been leaked
|
|
||||||
* I never saw a proper response and retro on how to prevent this from happening
|
|
||||||
* Not directly the result of compiler compromise, but no way to verify if software is tampered
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# What's the Answer?
|
|
||||||
|
|
||||||
* Integrity hashes are already widely used
|
|
||||||
* How do we use them to verify the integrity of software during build time, not after?
|
|
||||||
|
|
||||||
* Determinism / Reproducibility
|
|
||||||
* > Method of building software which ensures that the resulting binary for
|
|
||||||
a piece of software is always bit-for-bit identical.
|
|
||||||
|
|
||||||
* When something is bit-for-bit identical each time it is _deterministic_
|
|
||||||
|
|
||||||
* Once something is _deterministic_, it can be _reproduced_
|
|
||||||
|
|
||||||
<!--
|
|
||||||
|
|
||||||
* We use integrity hashes to ensure that the software is not modified between the download source (CDN etc.) and end user
|
|
||||||
|
|
||||||
* You may be thinking that it's likely that most software is already deterministic by default - but it's not. This is because of things like time stamps, linking order, compilation flags, environment variables etc.
|
|
||||||
|
|
||||||
* This becomes very powerful when we start to reproduce the same software in
|
|
||||||
multiple different environments, and by different agents. Different hardware,
|
|
||||||
different OS, different person etc.
|
|
||||||
|
|
||||||
* So determinism is the method that allows us to easily and quickly check if
|
|
||||||
something new has been added to a binary
|
|
||||||
|
|
||||||
* How do we apply this to our tech stack?
|
|
||||||
-->
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* In this example, we see the same software built deterministically in several different environments.
|
|
||||||
|
|
||||||
* Because it's determnistic, we know that we expect the same hash on all systems
|
|
||||||
|
|
||||||
* We easily notice that Azure produced a binary that hashes to a different value, and therefore know something is different about this binary
|
|
||||||
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# How Deep Do We Have to Go?
|
|
||||||
|
|
||||||
* Software Application
|
|
||||||
* First Party Code
|
|
||||||
* Third Party Code
|
|
||||||
|
|
||||||
* Build and Runtime Environment
|
|
||||||
* Operating System + Packages
|
|
||||||
* Additional CLI / Tools
|
|
||||||
|
|
||||||
* Compiler
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* We need everything to be deterministic - this is not how software is currently built
|
|
||||||
* And yes this is not simple to do... so let's talk about how we can achieve this
|
|
||||||
* As a side note, a similar apporach applies to interpreted languages like javascript, where can hash the source code of the application, and use a deterministically built environment and runtime.
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Adequate Solution
|
|
||||||
|
|
||||||
* Allows us to make the whole tree deterministic
|
|
||||||
|
|
||||||
* Can be easily reproduced
|
|
||||||
|
|
||||||
* Drop in replacement / easy to upgrade
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Bootstrapping our Way Up
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Who Compiles the Compiler?
|
|
||||||
|
|
||||||
* Mostly downloaded as a binary
|
|
||||||
|
|
||||||
* Even if the compiler is built from source, usually another compiler is used to do so
|
|
||||||
|
|
||||||
* This means there is no clear providence to how we went from nothing to having a usable compiler
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* Maintainers of open source software are the people that often are the ones building this software, and even in large organizations like Microsoft and Apple, they are not using determinism
|
|
||||||
|
|
||||||
* We can also rely on reverse engineering but it's not a reliable and practical method
|
|
||||||
|
|
||||||
* So the very foundation of how we build software is not verifiable... that's a problem
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Bootstrapping Compilers
|
|
||||||
|
|
||||||
* Consists of "stages", and hundreds of steps of starting from a human auditable rudimentary compiler and building up all the way up to a modern compiler
|
|
||||||
|
|
||||||
* Bootstrapping programming languages
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* Complicated but auditable process
|
|
||||||
|
|
||||||
* We want to do this deterministically of course so we have a tamper evidence method
|
|
||||||
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# We Have a Compiler, Now What?
|
|
||||||
|
|
||||||
* Build all of the different dependencies we need:
|
|
||||||
* `linux kernel`
|
|
||||||
* `bash`
|
|
||||||
* `openssl`
|
|
||||||
* `git`
|
|
||||||
* Yes... I mean *everything* in your build environment
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Status Check-In
|
|
||||||
|
|
||||||
* So far we have established we need the following for a solution:
|
|
||||||
* Bootstrap a compiler in a deterministic manner
|
|
||||||
* Use compiler to build all our dependencies
|
|
||||||
* Last thing remaining: your application
|
|
||||||
|
|
||||||
<!-- Now this seems like a lot... and it is, so we went ahead and built
|
|
||||||
an open source solution that tries to address the problem -->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# [Stageˣ]
|
|
||||||
|
|
||||||
Open source Linux Distribution
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Multi-Signed, Bootstrapped, Deterministic, and Minimal
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
|
||||||
|
|
||||||
* Most Linux distributions are built for *compatibility* rather than *security*. This results in a dramatic increase of attack surface area of an operating
|
|
||||||
system.
|
|
||||||
|
|
||||||
* StageX is the first Linux multisig distribution, is one of two fully
|
|
||||||
bootstrapped Linux distributions, is 100% reproducible and deterministic,
|
|
||||||
and can build complicated software with as few dependencies exposed as
|
|
||||||
possible.
|
|
||||||
|
|
||||||
* The other thing that differentiates StageX from other solutions like NixOS
|
|
||||||
is that it is fully container native, so there is no package manager required
|
|
||||||
such as flake or otherwise.
|
|
||||||
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
<hr />
|
|
||||||
|
|
||||||
| Distribution | Signatures | Libc | Bootstrapped | Reproducible | Rust deps |
|
|
||||||
|--------------|------------|-------|--------------|--------------|----------:|
|
|
||||||
| Stagex | 2+ Human | Musl | Yes | Yes | 4 |
|
|
||||||
| Debian | 1 Human | Glibc | No | Partial | 231 |
|
|
||||||
| Arch | 1 Human | Glibc | No | Partial | 127 |
|
|
||||||
| Fedora | 1 Bot | Glibc | No | No | 167 |
|
|
||||||
| Alpine | None | Musl | No | No | 41 |
|
|
||||||
|
|
||||||
<!-- NOTE: "Rust deps" is the amount of dependencies required to build a Rust
|
|
||||||
hello world -->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Full source bootstrapped from Stage 0
|
|
||||||
|
|
||||||
From a 256-byte compiler written in hex0, StageX bootstraps all the compiler
|
|
||||||
tools necessary to build the distribution, 100% deterministically.
|
|
||||||
|
|
||||||
- Stage 0: Getting a basic C compiler on x86
|
|
||||||
- Stage 1: Building GCC for x86
|
|
||||||
- Stage 2: Upgrading GCC for x86_64
|
|
||||||
- Stage 3: Building up-to-date toolchains
|
|
||||||
- Stage X: Shipping the software you know and love
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# A Rust Example
|
|
||||||
|
|
||||||
```dockerfile
|
|
||||||
FROM stagex/pallet-rust@sha256:b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c AS build
|
|
||||||
ADD . /src
|
|
||||||
WORKDIR /src
|
|
||||||
ARG TARGET x86_64-unknown-linux-musl
|
|
||||||
RUN cargo build --release --target ${TARGET}
|
|
||||||
|
|
||||||
FROM scratch
|
|
||||||
COPY --from=build /app/target/${TARGET}/release/hello /usr/bin/hello
|
|
||||||
CMD ["/usr/bin/hello"]
|
|
||||||
```
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* This may look very similar to what you may do with alpine linux, but the difference is that with alpine you are trusting single points of failure since none of the alpine packages are multi reproduced and signed - this
|
|
||||||
is why we made stagex - they also do not use bootstrapped compilers.
|
|
||||||
|
|
||||||
* Who built alpine rust; what compiler did they use
|
|
||||||
|
|
||||||
* There is no way to easily reproduce most software so you can't verify it for yourself, you are blindly trusting that the binary is clean
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# All packages in StageX are:
|
|
||||||
|
|
||||||
* Built using hash-locked sources
|
|
||||||
* Confirmed reproducible by multiple developers
|
|
||||||
* Signed by multiple release maintainers
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
|
||||||
To ensure StageX remains a secure toolchain, there's some additional
|
|
||||||
maintenance that is performed compared to most distributions. This includes:
|
|
||||||
|
|
||||||
* Built using hash-locked sources. This ensures every developer gets the exact same copy of the code for each container, so no middleman could inject
|
|
||||||
malware, which helps with:
|
|
||||||
* Reproducing projects, ensuring they're built deterministically. This confirms
|
|
||||||
that no single developer, nor their machine, have been compromised. Once each
|
|
||||||
package is confirmed, they are...
|
|
||||||
* Signed by the release maintainers. These maintainers each build a copy of the
|
|
||||||
package locally and sign the containers with an OCI-compliant signature using
|
|
||||||
well-known OpenPGP keys.
|
|
||||||
---
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!--
|
|
||||||
flowchart TB
|
|
||||||
Build1[Build] --\> Reproduce1[Reproduce]
|
|
||||||
Build2[Build] --\> Reproduce2[Reproduce]
|
|
||||||
Reproduce1 --\> Sign1[Sign]
|
|
||||||
Reproduce2 --\> Sign2[Sign]
|
|
||||||
Sign1 --\> Release
|
|
||||||
Sign2 --\> Release
|
|
||||||
|
|
||||||
{
|
|
||||||
"theme": "light",
|
|
||||||
"themeCSS": ".label foreignObject { overflow: visible; }"
|
|
||||||
}
|
|
||||||
-->
|
|
||||||
|
|
||||||
<!-- TODO: talk about bootstrapping, incl. corrupt compilers in distro
|
|
||||||
toolchain -->
|
|
||||||
|
|
||||||
<!-- https://distrowatch.com/images/other/distro-family-tree.png -->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Multi-Signed OCI Images
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
|
||||||
|
|
||||||
* We have multiple individuals rebuild the all of the software in the StageX distribution
|
|
||||||
|
|
||||||
* You can also clone the stagex repository, install docker and run the command `make` to verify for yourself that all the hashes match
|
|
||||||
|
|
||||||
* You can overlay rules around how many times software has to have been rebuilt, and a trusted list of cryptographic keys the software has to be signed by to ensure you always have a desired level of reproduciblity in your stack
|
|
||||||
|
|
||||||
---
|
|
||||||
-->
|
|
||||||
|
|
||||||
[](https://mermaid.ink/svg/pako:eNpdklFrgzAQx79KuGdbV91s62DQpmNPZbDube4hJqdmRFNi7Cjid1-sa7EGAvn_f3c5LpcWuBYIMWRK__KCGUs-d0lF3NpvvvZMVtZtNGTzTWazF_Km_-F2DLcTSMeQTuBmkJReb5poOtFD_EdT27uEkUFvBnhQoimZFK6ltscJ2AJLTCB2RyXzwibgjQA9HAY2VyxFRTJtUObVe_qD3JKW6BOa_m1icpK1TBU-ky6BpOpcKdZYfThXHGJrGvTA6CYvIM6Yqp1qjoJZ3EmWG1ZeQwbzVUirzS1SaSbQyRbs-dgPI5eXVriuMpn3fmOUswtrj3Xs-z2e59IWTTrnuvRrKfrJFad15EdBtGJBiNEyZE9hKHi6WK-y4HGRieXDImDQdR7gpf5-mPzlA3R_HuyhBw)
|
|
||||||
|
|
||||||
<!--
|
|
||||||
flowchart TD
|
|
||||||
MA[Maintainer A] --\> Go
|
|
||||||
MB[Maintainer B] --\> Go
|
|
||||||
MC[Maintainer C] --\> Go
|
|
||||||
MA --\> GCC
|
|
||||||
MB --\> GCC
|
|
||||||
MC --\> GCC
|
|
||||||
MA --\> Rust
|
|
||||||
MB --\> Rust
|
|
||||||
MC --\> Rust
|
|
||||||
|
|
||||||
{
|
|
||||||
"theme": "light",
|
|
||||||
"themeCSS": ".label foreignObject { overflow: visible; }"
|
|
||||||
}
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Pallets
|
|
||||||
|
|
||||||
StageX will soon offer prebuilt containers including all the packages necessary to run some of our most used software, such as:
|
|
||||||
|
|
||||||
- `rust`
|
|
||||||
- `go`
|
|
||||||
- `nodejs`
|
|
||||||
- `nginx`
|
|
||||||
- `redis`
|
|
||||||
- `postgres`
|
|
||||||
|
|
||||||
<!--
|
|
||||||
* We already offer packages that can be used today, and are used in production by multiple companies
|
|
||||||
|
|
||||||
* Adding a usability improvement where all the dependencies are grouped into what we are calling "pallets"
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Key Takeaways
|
|
||||||
|
|
||||||
* Bootstrapped compiler
|
|
||||||
* Fully deterministic
|
|
||||||
* Packages the software you're already using, but in a more secure manner.
|
|
||||||
* Is a drop in replacement, and has native container support
|
|
||||||
|
|
||||||
<!--
|
|
||||||
|
|
||||||
Other distributions run their own package manager inside of containers
|
|
||||||
We use containers as our package manager 100% container native, no attack surface
|
|
||||||
* Package managers are notorious for introducing attack surfaces, such as arbitrary execution of `setup.py` or post-download scripts, and by using Docker
|
|
||||||
as our package manager, we avoid all forms of spontaneous execution.
|
|
||||||
|
|
||||||
All StageX software is built deterministically, meaning you can be sure all
|
|
||||||
components listed in your Software Bill Of Materials hasn't been tampered with.
|
|
||||||
Because StageX provides a toolchain for you to build your software in the same
|
|
||||||
manner
|
|
||||||
|
|
||||||
* Available on docker hub
|
|
||||||
|
|
||||||
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# What's Next?
|
|
||||||
|
|
||||||
* Adding SBOM
|
|
||||||
|
|
||||||
* Packaging more software
|
|
||||||
|
|
||||||
* Fully automating software updates
|
|
||||||
|
|
||||||
* Additional container runtimes like Podman and Kaniko
|
|
||||||
|
|
||||||
* Additional chip architecture support such as ARM and RISC-V
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# How You Can Help
|
|
||||||
|
|
||||||
* Provide feedback
|
|
||||||
|
|
||||||
* Support with development efforts
|
|
||||||
|
|
||||||
* Become a sponsor
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Links
|
|
||||||
|
|
||||||
**Email**: anton@distrust.co / sales@distrust.co
|
|
||||||
|
|
||||||
**Matrix Chat**: #stagex:matrix.org
|
|
||||||
|
|
||||||
**Docker Hub**: https://hub.docker.com/u/stagex
|
|
||||||
|
|
||||||
**Git Repo**: https://codeberg.org/stagex/stagex
|
|
||||||
|
|
||||||
Big thank you to sponsors who have supported the development of this project:
|
|
||||||
|
|
||||||
**Turnkey, Distrust, Mysten Labs**
|
|
||||||
|
|
||||||
Thank you to InCyber for hosting this fantastic event!
|
|
||||||
410
stagex/index.md
410
stagex/index.md
|
|
@ -1,414 +1,103 @@
|
||||||
---
|
---
|
||||||
|
theme: gaia
|
||||||
_class: lead
|
_class: lead
|
||||||
paginate: true
|
paginate: true
|
||||||
backgroundColor: #fff
|
backgroundColor: #fff
|
||||||
---
|
---
|
||||||
|
|
||||||
<style>
|
|
||||||
/* Changed in Marp 4.0.0. Re-center. */
|
|
||||||
section.lead {
|
|
||||||
display: flex;
|
|
||||||
}
|
|
||||||
|
|
||||||
div.two-columns {
|
|
||||||
column-count: 2;
|
|
||||||
}
|
|
||||||
</style>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
# Bootstrapping Reproducibility with StageX
|
Minimalism and security first repository of reproducible and multi-signed OCI images of common open source software toolchains full-source bootstrapped from Stage 0 all the way up.
|
||||||
|
|
||||||
The steps involved in going from a 256 byte compiler to a deterministic
|
|
||||||
bit-for-bit reproducible Linux distribution.
|
|
||||||
|
|
||||||
<!--
|
|
||||||
Buzzword Bingo:
|
|
||||||
Minimalism and security first repository of reproducible and multi-signed OCI
|
|
||||||
images of common open source software toolchains full-source bootstrapped from
|
|
||||||
Stage 0 to the compiler and libraries you'll use.
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# The Problem: Is Your Toolchain Secure?
|
# **Minimalism and security first repository**
|
||||||
|
|
||||||
<!--
|
Most Linux distributions are built for **compatibility** rather than **security**
|
||||||
At some point in time, your Rust installation was tampered with. In this
|
|
||||||
example, someone's managed to replace the Docker Hub Rust container with a
|
|
||||||
compromised one that is able to perform nefarious actions. Let's see what
|
|
||||||
happens when it runs.
|
|
||||||
|
|
||||||
Play video with:
|
This results in a dramatic increase of attack surface area of an operating system
|
||||||
|
|
||||||
```sh
|
StageX is designed to allow the creation of application specific environments with a minimal footprint to eliminate attack surface area.
|
||||||
docker build -t mnemonicgen .
|
|
||||||
docker run mnemonicgen
|
|
||||||
```
|
|
||||||
|
|
||||||
Do you know who built _your_ Rust compiler?
|
---
|
||||||
-->
|
|
||||||
|
|
||||||
<!--
|
# Rust "hello world"
|
||||||
Anti-demo: Generate a Bitcoin wallet using "stonkx" which has a corrupt Rust
|
|
||||||
compiler. Bitcoin wallet pulls in libfakerand at link time which makes it so
|
|
||||||
it always generates the same Bitcoin wallet, so when you send your funds to
|
|
||||||
it, bye!
|
|
||||||
|
|
||||||
Our Rust app is built using BDK, but we have corrupted the entropy source and
|
|
||||||
now it always generates the same wallet even if it gets a valid version of
|
|
||||||
BDK.
|
|
||||||
-->
|
|
||||||
|
|
||||||
```dockerfile
|
```dockerfile
|
||||||
FROM stagex/openssl
|
FROM stagex/busybox as build
|
||||||
COPY --from=stagex/musl . /
|
COPY --from=stagex/rust . /
|
||||||
ENTRYPOINT ["/usr/bin/openssl"]
|
COPY --from=stagex/gcc . /
|
||||||
CMD ["rand", "-hex", "12"]
|
COPY --from=stagex/binutils . /
|
||||||
|
COPY --from=stagex/libunwind . /
|
||||||
|
RUN printf 'fn main(){ println!("Hello World!"); }' > hello.rs
|
||||||
|
RUN rustc hello.rs
|
||||||
|
FROM scratch
|
||||||
|
COPY --from=build /home/user/hello .
|
||||||
|
CMD ["./hello"]
|
||||||
```
|
```
|
||||||
|
---
|
||||||
|
|
||||||
<hr />
|
# **Reproducible and multi-signed**
|
||||||
|
|
||||||
<div class="two-columns">
|
All packages provided by StageX are built deterministically
|
||||||
|
|
||||||
<div>
|
All packages are reproduced by multiple developers to ensure their integrity
|
||||||
|
|
||||||
```sh
|
All packages are signed by well-known PGP keys after being successfully reproduced
|
||||||
docker build -t stagex/openssl -f stagex-openssl.Containerfile .
|
|
||||||
docker run stagex/openssl
|
|
||||||
# Output: 2a2a2a2a2a2a2a2a2a2a2a2a
|
|
||||||
```
|
|
||||||
|
|
||||||
</div>
|
|
||||||
|
|
||||||
<div>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
</div>
|
|
||||||
|
|
||||||
</div>
|
|
||||||
|
|
||||||
<!-- Include link to repo -->
|
|
||||||
|
|
||||||
<!--
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Credentials slide
|
# **OCI images**
|
||||||
|
|
||||||
-->
|
StageX uses an open standard for images in order to allow the use of different container runtimes
|
||||||
|
|
||||||
|
OCI images makes StageX portable and easy to reproduce on all AMD based systems
|
||||||
|
|
||||||
|
The only available target at the moment is AMD.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Minimalism and security first Linux distribution
|
# **Common open source software**
|
||||||
|
|
||||||
Approach the development of a secure toolchain by ensuring each component uses
|
StageX supports 100+ packages, with a focus on supporting software commonly used by developers
|
||||||
exactly what it needs to build - no more, no less.
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
Some of the currently available packages include: `curl`, `rust`, `git`, `go`, `bash`, `tofu`...
|
||||||
Most Linux distributions are built for *compatibility* rather than *security*.
|
|
||||||
This results in a dramatic increase of attack surface area of an operating
|
|
||||||
system. StageX is designed to allow the creation of application specific
|
|
||||||
environments with a minimal footprint to eliminate attack surface area. Each
|
|
||||||
component of the toolchain installs only what it needs, and only packages what
|
|
||||||
it builds, resulting in a decreased attack surface.
|
|
||||||
|
|
||||||
StageX is the first Linux multisig distribution, is one of two fully
|
If you are interested in additionally software being added feel free to open a PR or let us know what you would like to see added.
|
||||||
bootstrapped Linux distributions, is 100% reproducible and deterministic,
|
|
||||||
and can build complicated software with as few dependencies exposed as
|
|
||||||
possible.
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
<hr />
|
|
||||||
|
|
||||||
<!--
|
|
||||||
TODO: include image describing traditional package building, by installing
|
|
||||||
_every_ dependency in a single OS, with a comparison of stagex only having mini
|
|
||||||
Containerfiles with just what each project needs. If done so, this graph can be
|
|
||||||
moved to a separate slide.
|
|
||||||
-->
|
|
||||||
|
|
||||||
| Distribution | Signatures | Libc | Bootstrapped | Reproducible | Rust deps |
|
|
||||||
|--------------|------------|-------|--------------|--------------|----------:|
|
|
||||||
| Stagex | 2+ Human | Musl | Yes | Yes | 4 |
|
|
||||||
| Debian | 1 Human | Glibc | No | Partial | 231 |
|
|
||||||
| Arch | 1 Human | Glibc | No | Partial | 127 |
|
|
||||||
| Fedora | 1 Bot | Glibc | No | No | 167 |
|
|
||||||
| Alpine | None | Musl | No | No | 41 |
|
|
||||||
|
|
||||||
<!-- NOTE: "Rust deps" is the amount of dependencies required to build a Rust
|
|
||||||
hello world -->
|
|
||||||
|
|
||||||
<!---
|
|
||||||
-- Unable to confirm the following:
|
|
||||||
| Guix | 1 Human | Glibc | Yes | Yes | 4 |
|
|
||||||
| Nix | 1 Bot | Glibc | Partial | Mostly | 4 |
|
|
||||||
--->
|
|
||||||
|
|
||||||
<!-- Add a link to a script that confirms/reproduces the dependency count for
|
|
||||||
building Rust hello world -->
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# A Rust Example
|
# **Full source bootstrapped from Stage 0**
|
||||||
|
|
||||||
```dockerfile
|
The StageX compiler and all libraries necessary to build software are themselves fully bootstrapped and deterministic
|
||||||
FROM scratch AS fetch
|
|
||||||
ADD . /app
|
|
||||||
WORKDIR /app
|
|
||||||
|
|
||||||
FROM stagex/pallet-rust AS build
|
Bootstrapped - built up from "nothing" in order to allow verification of how the compiler is built - ensuring there is no malicious code added to it at any point.
|
||||||
COPY --from=fetch . /
|
|
||||||
COPY --from=stagex/nettle . /
|
|
||||||
COPY --from=stagex/gmp . /
|
|
||||||
ENV TARGET=x86_64-unknown-linux-musl
|
|
||||||
RUN cargo build --release --target $TARGET
|
|
||||||
|
|
||||||
FROM stagex/filesystem AS package
|
Ken Thompson describes the risk of using a compiler which can't be verified to be trustworthy in his seminal paper "Reflections on Trusting Trust"
|
||||||
COPY --from=build /app/target/$TARGET/release/hello /usr/bin/hello
|
|
||||||
CMD ["/usr/bin/hello"]
|
|
||||||
```
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
|
||||||
In this example, note how we are only pulling in Rust and the dependencies
|
|
||||||
required to invoke Rust. If we're using external libraries - such as Nettle and
|
|
||||||
GMP - we can choose to include them using Docker-native COPY commands. We don't
|
|
||||||
include anything extra, which reduces attack surface when compiling software.
|
|
||||||
---
|
|
||||||
-->
|
|
||||||
|
|
||||||
<!-- TODO: make pallets a thing, test this. Include RUSTFLAGS to make static in
|
|
||||||
the pallet -->
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# All packages in StageX are:
|
# **OK, So What?**
|
||||||
|
|
||||||
* Built using hash-locked sources
|
There is an entire family of supply chain vulnerabilities which can be eliminated by using StageX
|
||||||
* Confirmed reproducible by multiple developers
|
|
||||||
* Signed by multiple release maintainers
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
By reducing the number of dependencies needed to run and build software, we remove unnecessary software which can act as an entry point for malicious software such as malware
|
||||||
To ensure StageX remains a secure toolchain, there's some additional
|
|
||||||
maintenance that is performed compared to most distributions. This includes:
|
|
||||||
|
|
||||||
* Built using hash-locked sources. This ensures every developer gets the exact
|
For example, if using Debian as a base for `rust`, one ends up using **232 dependencies**, where as StageX only requires **4 dependencies**
|
||||||
same copy of the code for each container, so no middleman could inject
|
|
||||||
malware, which helps with:
|
|
||||||
* Reproducing projects, ensuring they're built deterministically. This confirms
|
|
||||||
that no single developer, nor their machine, have been compromised. Once each
|
|
||||||
package is confirmed, they are...
|
|
||||||
* Signed by the release maintainers. These maintainers each build a copy of the
|
|
||||||
package locally and sign the containers with an OCI-compliant signature using
|
|
||||||
well-known OpenPGP keys.
|
|
||||||
---
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!--
|
|
||||||
flowchart TB
|
|
||||||
Build1[Build] --\> Reproduce1[Reproduce]
|
|
||||||
Build2[Build] --\> Reproduce2[Reproduce]
|
|
||||||
Reproduce1 --\> Sign1[Sign]
|
|
||||||
Reproduce2 --\> Sign2[Sign]
|
|
||||||
Sign1 --\> Release
|
|
||||||
Sign2 --\> Release
|
|
||||||
|
|
||||||
{
|
|
||||||
"theme": "light",
|
|
||||||
"themeCSS": ".label foreignObject { overflow: visible; }"
|
|
||||||
}
|
|
||||||
-->
|
|
||||||
|
|
||||||
<!-- TODO: talk about bootstrapping, incl. corrupt compilers in distro
|
|
||||||
toolchain -->
|
|
||||||
|
|
||||||
<!-- https://distrowatch.com/images/other/distro-family-tree.png -->
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Multi-Signed OCI Images
|
Additionally, there has not been a simple way to verify that a compiler is trusted.
|
||||||
|
|
||||||
Multiple maintainers can each sign individual images, with the container
|
This is because compilers are used to build other compilers, and for a long time, we lost the ability to build up a compiler toolchain from "nothing"
|
||||||
runtime enforcing _multiple_ signatures by maintainers to ensure no individual
|
|
||||||
maintainer could have tampered with an image.
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
StageX allows us to bootstrap the compiler toolchain, making it easy to verify that no malicious code was introduced at any point, by reviewing the code, and it also does so in a deterministic manner, which makes it simple to further verify the integrity of the binary
|
||||||
StageX uses the Open Container Initiative standard for images to support the
|
|
||||||
use of multiple container runtimes. Because OCI images can be signed using
|
|
||||||
OpenPGP keys, this allows the association of built images to trusted
|
|
||||||
maintainers, which can enable developers to build their software using StageX,
|
|
||||||
without having to build the entire StageX toolchain for themselves.
|
|
||||||
|
|
||||||
Creating a network of trust builds a relationship between developers and
|
|
||||||
maintainers, allowing developers to choose maintainers that implement key
|
|
||||||
management policies that match their standards. For example, Distrust signing
|
|
||||||
keys are always stored on smart cards or airgapped machines, avoiding key
|
|
||||||
exfiltration attacks and limiting key exposure to trusted computation
|
|
||||||
environments.
|
|
||||||
---
|
|
||||||
-->
|
|
||||||
|
|
||||||
[](https://mermaid.ink/svg/pako:eNpdklFrgzAQx79KuGdbV91s62DQpmNPZbDube4hJqdmRFNi7Cjid1-sa7EGAvn_f3c5LpcWuBYIMWRK__KCGUs-d0lF3NpvvvZMVtZtNGTzTWazF_Km_-F2DLcTSMeQTuBmkJReb5poOtFD_EdT27uEkUFvBnhQoimZFK6ltscJ2AJLTCB2RyXzwibgjQA9HAY2VyxFRTJtUObVe_qD3JKW6BOa_m1icpK1TBU-ky6BpOpcKdZYfThXHGJrGvTA6CYvIM6Yqp1qjoJZ3EmWG1ZeQwbzVUirzS1SaSbQyRbs-dgPI5eXVriuMpn3fmOUswtrj3Xs-z2e59IWTTrnuvRrKfrJFad15EdBtGJBiNEyZE9hKHi6WK-y4HGRieXDImDQdR7gpf5-mPzlA3R_HuyhBw)
|
|
||||||
|
|
||||||
<!--
|
|
||||||
flowchart TD
|
|
||||||
MA[Maintainer A] --\> Go
|
|
||||||
MB[Maintainer B] --\> Go
|
|
||||||
MC[Maintainer C] --\> Go
|
|
||||||
MA --\> GCC
|
|
||||||
MB --\> GCC
|
|
||||||
MC --\> GCC
|
|
||||||
MA --\> Rust
|
|
||||||
MB --\> Rust
|
|
||||||
MC --\> Rust
|
|
||||||
|
|
||||||
{
|
|
||||||
"theme": "light",
|
|
||||||
"themeCSS": ".label foreignObject { overflow: visible; }"
|
|
||||||
}
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Common toolchain dependencies
|
# **What's Next?**
|
||||||
|
|
||||||
StageX comes with developer-loved tooling and languages, such as:
|
Packaging more software
|
||||||
|
|
||||||
- `rust`
|
|
||||||
- `go`
|
|
||||||
- `python`
|
|
||||||
- `curl`
|
|
||||||
- `git`
|
|
||||||
|
|
||||||
If you are interested in additionally software being added feel free to open a
|
|
||||||
PR or let us know what you would like to see added.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Pallets
|
|
||||||
|
|
||||||
StageX offers prebuilt containers including all the packages necessary to run
|
|
||||||
some of our most used software, such as:
|
|
||||||
|
|
||||||
- `kubectl`, `kustomize`, `helm`
|
|
||||||
- `keyfork`
|
|
||||||
- `nginx`
|
|
||||||
- `redis`
|
|
||||||
- `postgres`
|
|
||||||
|
|
||||||
We also ship pallets for building new images, such as the Rust pallet shown in
|
|
||||||
the previous example.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Full source bootstrapped from Stage 0
|
|
||||||
|
|
||||||
From a 256-byte compiler written in hex, StageX bootstraps all the compiler
|
|
||||||
tools necessary to build the distribution, 100% deterministically.
|
|
||||||
|
|
||||||
<!-- Who compiles the compiler? -->
|
|
||||||
|
|
||||||
- Stage 0: Getting a basic C compiler on x86
|
|
||||||
- Stage 1: Building GCC for x86
|
|
||||||
- Stage 2: Upgrading GCC for x86_64
|
|
||||||
- Stage 3: Building up-to-date toolchains
|
|
||||||
- Stage X: Shipping the software you know and love
|
|
||||||
|
|
||||||
<!-- Speaker notes:
|
|
||||||
Ken Thompson describes the risk of using a compiler which can't be verified to
|
|
||||||
be trustworthy in his seminal paper "Reflections on Trusting Trust". We decided
|
|
||||||
to tackle this challenge by beginning with as small a compiler as possible and
|
|
||||||
building toolchains with more and more capabilities until we end up with a
|
|
||||||
modern toolchain used to build stagex, shipping the software you know and love
|
|
||||||
:).
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# OK, So What?
|
|
||||||
|
|
||||||
By using stagex, an entire family of supply chain vulnerabilities can be
|
|
||||||
eliminated. Removing unnecessary software reduces the attack surface of
|
|
||||||
potentially malicious software, while deterministic builds help ensure
|
|
||||||
software hasn't been tampered with.
|
|
||||||
|
|
||||||
|
|
||||||
Because StageX can be used to build standalone Linux systems, it can also be
|
|
||||||
used to generate bootable images without needing to ship unnecessary tooling
|
|
||||||
such as a package manager or a compiler.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# _Solar Winds_ of Change
|
|
||||||
|
|
||||||
According to: https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/
|
|
||||||
|
|
||||||
> - SUNSPOT is StellarParticle’s malware used to insert the SUNBURST backdoor into software builds of the SolarWinds Orion IT management product.
|
|
||||||
> - SUNSPOT monitors running processes for those involved in compilation of the Orion product and replaces one of the source files to include the SUNBURST backdoor code.
|
|
||||||
> - Several safeguards were added to SUNSPOT to avoid the Orion builds from failing, potentially alerting developers to the adversary’s presence.
|
|
||||||
|
|
||||||
<!-- Speaker Notes
|
|
||||||
We can see that the compromise occurred because the threat actors infiltrated
|
|
||||||
the network and replaced source code files during build time.
|
|
||||||
|
|
||||||
This could have been prevented by ensuring builds were deterministic.
|
|
||||||
|
|
||||||
* Ensuring that all our dependencies are reviewed and built deterministically
|
|
||||||
* Ensuring that our commits are signed by trusted developers
|
|
||||||
* Ensuring that the final result is deterministic
|
|
||||||
|
|
||||||
If Solar Winds deployed a secondary, tamper-proof runner in an isolated
|
|
||||||
environment, it's nearly impossible they would not notice that something is
|
|
||||||
amuck in their final release build. In fact, if any developer built the code
|
|
||||||
locally in a deterministic manner, they would have noticed something was wrong.
|
|
||||||
|
|
||||||
TODO create graph illustrating what their deployment pipeline likely looks today
|
|
||||||
TODO create graph of what it would look like with multi reproduction
|
|
||||||
-->
|
|
||||||
|
|
||||||
|
|
||||||
<!--
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Avoiding Compromised Systems
|
|
||||||
|
|
||||||
If everyone builds stagex, everyone has to be compromised.
|
|
||||||
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Key Takeaways
|
|
||||||
|
|
||||||
* StageX packages the software you're already using, securely.
|
|
||||||
* By leveraging Docker, we avoid mixing package managers and build contexts.
|
|
||||||
* Your software, at every point in the bootstrapped toolchain, can all be built
|
|
||||||
deterministically.
|
|
||||||
|
|
||||||
<!--
|
|
||||||
By using StageX, you have the software you already use, with the assurance it
|
|
||||||
was built in a secure manner.
|
|
||||||
|
|
||||||
Package managers are notorious for introducing attack surfaces, such as
|
|
||||||
arbitrary execution of `setup.py` or post-download scripts, and by using Docker
|
|
||||||
as our package manager, we avoid all forms of spontaneous execution.
|
|
||||||
|
|
||||||
All StageX software is built deterministically, meaning you can be sure all
|
|
||||||
components listed in your Software Bill Of Materials hasn't been tampered with.
|
|
||||||
Because StageX provides a toolchain for you to build your software in the same
|
|
||||||
manner, your software can be sooper dooper pooper scooper secure.
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# What's Next?
|
|
||||||
|
|
||||||
Packaging more software and updating existing software faster
|
|
||||||
|
|
||||||
Adding additional container runtimes like Podman and Kaniko
|
Adding additional container runtimes like Podman and Kaniko
|
||||||
|
|
||||||
|
|
@ -416,7 +105,9 @@ Adding additional chip architecture support such as ARM and RISC-V
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Links
|
# **Links**
|
||||||
|
|
||||||
|
**Presenter**: <your_name>
|
||||||
|
|
||||||
**Matrix Chat**: #stagex:matrix.org
|
**Matrix Chat**: #stagex:matrix.org
|
||||||
|
|
||||||
|
|
@ -425,3 +116,6 @@ Adding additional chip architecture support such as ARM and RISC-V
|
||||||
Big thank you to sponsors who have supported the development of this project:
|
Big thank you to sponsors who have supported the development of this project:
|
||||||
|
|
||||||
**Turnkey, Distrust, Mysten Labs**
|
**Turnkey, Distrust, Mysten Labs**
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
#!/bin/sh
|
|
||||||
|
|
||||||
apk add cargo
|
|
||||||
printf "DEPS (Alpine): %s\n" $(apk list --installed | tail -n +2 | wc -l)
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
#!/bin/sh
|
|
||||||
|
|
||||||
pacman -Syu --noconfirm rust
|
|
||||||
printf "DEPS (Arch Linux): %s\n" $(pacman -Q | wc -l)
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
#!/bin/sh
|
|
||||||
|
|
||||||
apt-get update
|
|
||||||
apt-get install -y cargo rustc
|
|
||||||
printf "DEPS (Debian): %s\n" $(dpkg --get-selections | wc -l)
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
#!/bin/sh
|
|
||||||
|
|
||||||
yum install -y cargo
|
|
||||||
printf "DEPS (Fedora): %s\n" $(yum list installed | tail -n +2 | wc -l)
|
|
||||||
|
|
@ -1,7 +0,0 @@
|
||||||
#!/bin/sh
|
|
||||||
|
|
||||||
SCRIPTDIR="$(cd "$(dirname $0)"; pwd)"
|
|
||||||
|
|
||||||
for distro in debian archlinux fedora alpine; do
|
|
||||||
docker run --rm -v "$SCRIPTDIR:/scripts:ro" $distro /bin/sh /scripts/$distro.sh | grep --color "^DEPS"
|
|
||||||
done
|
|
||||||
|
|
@ -1,30 +0,0 @@
|
||||||
# vim:set ft=dockerfile:
|
|
||||||
FROM scratch AS libfakerand
|
|
||||||
COPY --from=stagex/busybox . /
|
|
||||||
COPY --from=stagex/rust . /
|
|
||||||
COPY --from=stagex/musl . /
|
|
||||||
COPY --from=stagex/gcc . /
|
|
||||||
COPY --from=stagex/llvm . /
|
|
||||||
COPY --from=stagex/binutils . /
|
|
||||||
COPY --from=stagex/libunwind . /
|
|
||||||
COPY --from=stagex/git . /
|
|
||||||
COPY --from=stagex/openssl . /
|
|
||||||
COPY --from=stagex/zlib . /
|
|
||||||
COPY --from=stagex/curl . /
|
|
||||||
COPY --from=stagex/ca-certificates . /
|
|
||||||
RUN git clone https://git.distrust.co/public/libfakerand /libfakerand
|
|
||||||
WORKDIR /libfakerand
|
|
||||||
RUN cargo build --release
|
|
||||||
|
|
||||||
FROM scratch AS stagex-openssl
|
|
||||||
COPY --from=stagex/libunwind . /
|
|
||||||
COPY --from=stagex/gcc . /
|
|
||||||
COPY --from=stagex/openssl . /
|
|
||||||
COPY --from=libfakerand /libfakerand/target/release/libfakerand.so /usr/lib/libfakerand.so
|
|
||||||
ENV LD_PRELOAD=/usr/lib/libfakerand.so
|
|
||||||
ENV FAKERAND=42
|
|
||||||
|
|
||||||
FROM stagex-openssl
|
|
||||||
COPY --from=stagex/musl . /
|
|
||||||
ENTRYPOINT ["/usr/bin/openssl"]
|
|
||||||
CMD ["rand", "-hex", "12"]
|
|
||||||
Loading…
Reference in New Issue