Defense in Depth - Security Scanning

[apyrgio]

Parent issue: #221

Attackers that want to escape the Dangerzone container, first need to find a vulnerability in the conversion software. Ensuring that no such vulnerabilities exist is the first layer of defense against attackers.

In practice, we can't guarantee that the installed software does not have any security vulnerabilities. However, what we can do is:

1. Continuously scan the dangerzone.rocks/dangerzone container image.
   • Use an open source scanner like Grype.
   • Use CircleCI to scan the image daily and report any findings.
2. Update the affected software if a Critical/High vulnerability is found.

[deeplow]

We may want to consider separating the container image from the software versions. Having to do a full release every time we do this, it may slow down development significantly necessarily. We'd have to somehow verify the container image's integrity and have some sort of anti-rollback mechanism to prevent avoid a malicious docker hub.

I believe @legoktm had showed interest specifically in this question. The additional benefit is that a 700MB can't be on any official repos, whereas a smaller .rpm or .deb can.

[legoktm]

Yes! See #154 for some more reasons on why to split the container out of the package.

We'd have to somehow verify the container image's integrity and have some sort of anti-rollback mechanism to prevent avoid a malicious docker hub.

You can pin to specific sha256 checksums, e.g. https://github.com/freedomofpress/securedrop/blob/develop/securedrop/dockerfiles/focal/python3/Dockerfile.

And supposedly you can GPG sign and verify containers (e.g. https://docs.podman.io/en/latest/markdown/podman-image-sign.1.html) but I've never tried that myself.

[deeplow]

Perfect. We'll have to look into that, then.

[deeplow]

Circle CI (which we're already using) has "scheduled" pipelines. It could be useful here.

[apyrgio]

I've made some progress on the security scanning front, and I'd like to write down my suggestion, for which I'll send a PR soon:

Items to scan

It seems to me that we should scan the following items, for completeness:

1. The application and more specifically its dependencies (i.e., poetry.lock)
2. The container images

Also, we need to scan the same items (application, container image) for the latest release as well (currently v0.4.1). This way, we are always aware about security issues both at the tip of our main branch, as well as the latest release.

CVE Handling

Security scans are bound to find lots of CVEs. Assessing those CVEs is important, but can take lots of time. So, for starters, we need to focus our energy on the CVEs that are important. My suggestion is to only consider CVEs with severity "Critical", and a fix present.

Suppose that a CVE that matches the above criteria is found by our security scanner. We can differentiate on the action we'll take based on where it was detected (main vs latest release):

• main branch, application CVE: We can bump the poetry.lock file, to get the new fix.
• main branch, container image CVE: We should check why the fix is not present in the Alpine Linux repos (rare).
• latest release, application / container CVE: We should assess if this CVE affects users. If not, placate the scanner by ignoring this CVE. If it does, we need to get a new release out (hopefully rare scenario).

Triggering CI workflows

We can run the security scans for pushes, PRs, and nightly, but we should make an exception for the released artifacts. Since any new code will not affect those, security scans for them should run nightly only. For CVEs that affect the main branch, it makes sense to run them per PR, to avoid introducing to the repo a vulnerable package version.