slsa
slsa copied to clipboard
slsa-framework
Dependencies, Operating System packages and pinning
Hello folks,
I have a question about version pinning in the context of compiled programs (mostly C and C++, i.e. those without built-in dependency tracking).
Most of these programs come with a build-system (GNU autotools, meson, CMake etc.) that checks for minimum versions of the dependencies and perhaps whether or not some functions are available. The resulting binaries are dynamically linked to the operating system's libraries.
These libraries are usually only updated by the maintainers for security reasons, where the fix is backported (i.e. same base version, with an added patch).
When building packages (debs, rpms) one of the steps in the build container is "install dependency packages" via apt/yum/dnf. This means the (sub-)version of a dependency can change when re-building the source into an operating system package.
How would the provenance and pinning work for this? Would one need to keep images around of every OS snapshot? Or would a dependency of "libfoo" with a minimum version be ok when using OS provided packages? Perhaps by recording the versions that were installed during the build into the provenance?
Perhaps by recording the versions that were installed during the build into the provenance?
Yep that's basically the idea! Capturing the package metadata (preferably provenance, version+digest also works) should give you a detailed enough description of the build environment to be useful. That said, stock distros tend to have many packages installed by default so even in a simple build on a normal OS, the number of dependencies tends to be large.
This base level exposure/risk is a big reason why using containerized build environments based on low-dependency images (alpine, distroless, etc).
Yep that's basically the idea! Capturing the package metadata (preferably provenance, version+digest also works) should give you a detailed enough description of the build environment to be useful.
Right! Making a complete replica-environment to reproduce the build is another thing, as it could require the use of archives of older packages. Although the resulting binary should not change.
This base level exposure/risk is a big reason why using containerized build environments based on low-dependency images (alpine, distroless, etc).
Sure, but that won't work if you're building rpms/debs :smile:
Would it make sense to have a slsa chapter on operating system binary artifacts (packages)?
In the interest of getting things done I think rather than SLSA starting from scratch we can rely on the great work already done around reproducibility
https://reproducible-builds.org/docs/deterministic-build-systems/
https://reproducible-builds.org/docs/perimeter/
https://reproducible-builds.org/docs/virtual-machine-drivers/
https://reproducible-builds.org/docs/rebuilders/
https://reproducible-builds.org/projects/
https://salsa.debian.org/reproducible-builds/disorderfs
As for the questions around dynamic links you could move to a statically linked output. You could build using a statically linked gcc too to avoid needing to record the specific gcc version and glibc version you had linked at the time.
Or you can still in theory reproduce a dynamically linked result as long as you record the specific gcc version and glibc version you had linked at the time. You might also use this info to mandate/recomend a specific glibc version.
nix patches links to be fixed within the store to a specific version https://github.com/NixOS/patchelf (or just builds them from scratch that way) and NixOS doesn't provide any libs so there's nothing to dynamically link against/use
λ ls -al /lib
lsd: /lib: No such file or directory (os error 2).
λ ldd $(which cp)
linux-vdso.so.1 (0x00007ffcf82b3000)
librt.so.1 => /nix/store/2jfn3d7vyj7h0h6lmh510rz31db68l1i-glibc-2.33-50/lib/librt.so.1 (0x00007f605eb44000)
libacl.so.1 => /nix/store/2lhvry743cmjr60h3pkahs2cn1azg3mx-acl-2.3.1/lib/libacl.so.1 (0x00007f605eb39000)
libattr.so.1 => /nix/store/mh4qx7hrcs1cnjlvgfmlv2j0bwpypqs1-attr-2.5.1/lib/libattr.so.1 (0x00007f605eb31000)
libcrypto.so.1.1 => /nix/store/55fxsnk1cr4hbvgj1zcq9gqwvcw9cgy4-openssl-1.1.1l/lib/libcrypto.so.1.1 (0x00007f605e844000)
libpthread.so.0 => /nix/store/2jfn3d7vyj7h0h6lmh510rz31db68l1i-glibc-2.33-50/lib/libpthread.so.0 (0x00007f605e824000)
libc.so.6 => /nix/store/2jfn3d7vyj7h0h6lmh510rz31db68l1i-glibc-2.33-50/lib/libc.so.6 (0x00007f605e65d000)
libdl.so.2 => /nix/store/2jfn3d7vyj7h0h6lmh510rz31db68l1i-glibc-2.33-50/lib/libdl.so.2 (0x00007f605e658000)
/nix/store/2jfn3d7vyj7h0h6lmh510rz31db68l1i-glibc-2.33-50/lib/ld-linux-x86-64.so.2 => /nix/store/2jfn3d7vyj7h0h6lmh510rz31db68l1i-glibc-2.33-50/lib64/ld-linux-x86-64.so.2 (0x00007f605eb51000)
