Improve build security

[ben-grande]

Problem

Currently, Mirage Firewall is aiming to reproducible builds. But can it also improve the build security?

I read the git blames but they didn't inform the implications of these lines, just why they were need, for reproducibility.

0. Can apt-transport-https be installed before setting the debian snapshot so debian packages will be fetched over https for defense in depth against a failure of dpkg signature verification, which happens from time to time. I am proposing an apt upgrade and apt install -y --no-install-recommends apt-transport-tor and change the repo definition of the snapshot to use https. Will this break reproducibility because this package will not be pinned to a specific debian snapshot?

1. download of Opam without signature verification, although the release packages have a companion .sig signature file. Would need to save the Opam release public key to this repo and place it in the docker container.

2. Why is OPAMCONFIRMLEVEL=unsafe-yes require? What insecurities can it bring? I know this is Opam specific and not qubes-mirage-firewall, but I didn't understand the implications from reading the manpage.

3. Why is --disable-sandboxing needed? Is this to downgrade the opam version to be pinnned?

4. Is Opam fetching through https 0 1 solely? This is also Opam specific, Opam does not do package signature verification? If it does not do, this is an upstream problem and serves only as an information for me as it can't be fixed here. I have not found information that Opam does software verifications besides the CA certificates.

Summary

Analysis:

• 0: probably interferes with reproducible builds;
• 1: I know that can be solved;
• 2,3: I don't understand the implications;
• 4: probably dependent on upstream changes.

Request

I think it is important to document why those methods were used, via code comment or reflog.

Update

0. Waiting for resolution
1. Todo: Opam binary checksum
2. Waiting upstream: Issue opened upstream to document unsafe-yes
3. Can't be fixed: Sandboxing requires privileged container, here is a more detailed explanation
4. Solved: Opam packages checksum

[palainp]

Thanks for your review.

• 0: I don't know how this can interfere with the reproducibility goal, as the debian image first points to the debian repositories, right after the apt update call, can we rewind the time and point to older snapshots? (I first tried to use https but was unable to install the ca-certificates package without running apt update first)
• 1: it definitely can be solved with a hardcoded signature verification
• 2: comes from https://opam.ocaml.org/blog/opam-2-1-0/ which indicates to use this variable for non interactive launches, it always suppose the user answer is yes
• 3: to my understanding the opam sandboxing is needed to avoid opam access system wide. The documentation tells it can be used in unprivileged containers (and we probably need that for poushing {duniverse, _build, etc.} to the working directory?).
• 4: I don't have a deeper enough knowledge here, opam packages do have hash (e.g. https://github.com/ocaml/opam-repository/blob/master/packages/mirage/mirage.4.4.0/opam) so I guess every downloads are checked by default.

Maybe @kit-ty-kate has a better insight vision about 2,3 and 4 ?

[ben-grande]

• 0: yes, you can't install anything on a new system without updating the package list. I am afraid that a different apt-transport-https will break the build, but I don't know how often it is releases, maybe not much.
• 1: great.
• 2: also ok, but the unsafe name for non-interactive scares at first. If it means that is chooses an unsafe option with yes, that is unfortunate, but I understand it will be the only way to have unattended installs.

[hannesm]

Some notes: (0) I don't quite understand the implications, indeed fetching everything over https would be nice. But what would improve if we enforce everyone to use tor for fetching tarballs? (1) Indeed this should be improved to also download the signature, and the OpenPGP key, and verify the signature (2) opam may go out and install some system packages that are required by some opam package. This is crucial for non-interactive opam usage. I agree the description in the opam man page is not very helpful. I opened https://github.com/ocaml/opam/issues/5719 so that the opam developers will track it and improve it. (3) For some reason (that I do not remember), opam in unprivileged containers need to have sandboxing disabled. Now, the question is: can we fix it? Should we instead run the container as superuser and enable sandboxing? To me, this is a choice between the devil and the deep blue sea. (4) The short answer is yes: the metadata (URL + checksum) is specified in the opam-repository(/ies) -- which is verified by its sha (via git, pinned to a specific commit in this project here), and the tarballs are downloaded then and their checksum is validated.

The longer answer is that I had several iterations over its design, and am still working on supply chain security for opam. Briefly, based on TUF; practically not there yet.

[palainp]

I'm also not very fan of using tor as transport layer, we already had issues when downloading opam packages with whonix in Qubes (#86).

For checking opam binary, for simplicity, I'll probably compare against one hashsum available at https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh (e.g hardcode hashum in Docker "38802b3079eeceb27aab3465bfd0f9f05a710dccf9487eb35fa2c02fbaf9a0659e1447aa19dd36df9cd01f760229de28c523c08c1c86a3aa3f5e25dbe7b551dd" for the current one, it's just one more hash :) ).

[ben-grande]

(0) I don't quite understand the implications, indeed fetching everything over https would be nice. But what would improve if we enforce everyone to use tor for fetching tarballs?

With tor it would be slower but would solve the problem of having to use https.

(3) For some reason (that I do not remember), opam in unprivileged containers need to have sandboxing disabled. Now, the question is: can we fix it? Should we instead run the container as superuser and enable sandboxing? To me, this is a choice between the devil and the deep blue sea.

Now I understand the problem better, thank you. I'd rather have the unikernel be built with an unprivileged container.

(4) The short answer is yes: the metadata (URL + checksum) is specified in the opam-repository(/ies) -- which is verified by its sha (via git, pinned to a specific commit in this project here), and the tarballs are downloaded then and their checksum is validated.

The longer answer is that I had several iterations over its design, and am still working on supply chain security for opam. Briefly, based on TUF; practically not there yet.

Great to know it is being worked on and is being based on TUF model.

For checking opam binary, for simplicity, I'll probably compare against one hashsum available at https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh (e.g hardcode hashum in Docker "38802b3079eeceb27aab3465bfd0f9f05a710dccf9487eb35fa2c02fbaf9a0659e1447aa19dd36df9cd01f760229de28c523c08c1c86a3aa3f5e25dbe7b551dd" for the current one, it's just one more hash :) ).

Great, it would make the Opam download the same level as the rest.

[kit-ty-kate]

From what I’m reading everything was answered, maybe only (3) needs some context:

Running the bubblewrap sandbox inside of Docker is currently not possible without using docker run --privileged (option sadly not available for docker build). The upstream issue can be seen at https://github.com/containers/bubblewrap/issues/284. Running docker using root doesn’t change anything from what I know. The only two options that I know of would be to either use docker run --privileged or opam init --disable-sandboxing

EDIT: oops i hit enter too fast..

[palainp]

Thanks everyone, closed with #190