Repository: freedomofpress/dangerzone

Issue #222: Defense in Depth - Security Scanning
Created: 2022-10-17T12:33:35Z
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:

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.


Update the affected software if a Critical/High vulnerability is found.

Duplicate issue #221: Defense in Depth
Created: 2022-10-13T22:28:12Z
Primer
Dangerzone currently uses two containers (Docker containers on MacOS/Windows, Podman containers on Linux) for the conversion process:

The first container accepts a suspicious document/image as input, and produces a list of RGB files (corresponding to the pages of the document).
The second container accepts the list of RGB files, and produces the safe PDF document.

On this issue, we'll focus on protecting the users against an attacker who tries to take control of the first container.
Requirements
From the point where a conversion process reads an attacker payload, to the point where the attacker manages to escape to the host, there are several hurdles that they must jump. In order of importance, from the innermost hurdle to the outermost, these are the requirements from Dangerzone, to keep a user safe.

The attacker must not gain control of a process within the container.
The attacker must not access host data from within the container.
The attacker must not access the network from within the container.
The attacker must not become root within the container.
The attacker must not escape the container.
The attacker must not access host data outside the container.
The attacker must not become user/root outside the container.
The attacker must not escape the VM.

Current situation
The protective measures that Dangerzone has in place are:

(MacOS/Windows only) Containers run in VMs.

This is necessary, as this the only way that Docker Desktop can run Linux containers in the rest of the OSes.


The conversion process in the container is not / cannot become root.

The Dangerzone container image has a regular user in it, and the conversion process runs with their UID.
No process can elevate themselves to root, since no new privileges can be acquired.
See the relevant discussion: #169


Containers have no capabilities (see capabilities(7)).

We drop all capabilities when we create a new container, as we don't need them.
See the relevant PR: #183


Containers have no access to the network.

The question here is: can we improve on this situation even more?
Subtasks

 #228
 #225
 #227
 #226
 #222
 #224
 #223
 #633

Previous issues

#52
#169
#182

Closing comment (2022-10-13T23:11:09Z): Suggestions
We'll take each requirement we mentioned and try to suggest a protective measure that can aid in it:
1. The attacker must not gain control of a process within the container
Attackers will do so by exploiting a vulnerability in the image. We need to continuously monitor our container image for CVEs.
(Tracked in #222)
2. The attacker must not access host data from within the container
The container has limited visibility to files in the host, since we only mount two temporary directories in it (for input and output files). However, what we can do is figure out if we can avoid mounting proc and sysfs in it. See https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/ for a Docker exploit that heavily relied on procfs.
(Tracked in #223)
3. The attacker must not access the network from within the container
This should be fully covered.
4. The attacker must not become root within the container
This should already be covered by the fact that the user within the container is a regular user, and the fact that we use --security-opt=no-new-privileges. However, to further reduce the attack surface, we could follow the latest CIS Docker advisories (official link, mirror):

4.3 - Ensure that unnecessary packages are not installed in the container
4.8 - Ensure setuid and setgid permissions are removed
5.12 - Ensure that the container's root filesystem is mounted as read only

(Tracked in #224)
5. The attacker must not escape the container
The most important attack surface in a container is the Linux Kernel itself, and is what most attackers will try to exploit. A common countermeasure is to drop all capabilities, which we have already done, and have a strict seccomp profile.
(Tracked in #225)
6. The attacker must not access host data outside the container
There is a lot of room for improvement in this area. Sorted by acces control strictness:

SELinux (tracked in #226)
AppArmor (tracked in #227)
User namespaces (#228)

7. The attacker must not become user/root outside the container
This has to do with how up-to-date and hardened the Linux Kernel in the container host is. In Linux platforms, we don't have much we can do. In Windows/MacOS platforms, the Linux Kernel runs within a VM, so we may be able to take advantage of this.
8. The attacker must not escape the VM
Docker Desktop needs to mount the whole host in the guest VM, in order to use it for container mounts. See https://community.atlassian.com/t5/Trust-Security-articles/Hiding-malware-in-Docker-Desktop-s-virtual-machine/ba-p/1924743 on how this can be exploited.
An alternative to this would be to use MicroVMs. MicroVMs are small virtual machines that offer kernel isolation and small resource footprint, at the expense of some performance.
MicroVMs have already been paired with containers on some projects:

Kata Containers: https://katacontainers.io/
Krun: https://github.com/containers/krunvm

Note that this technology is still nascent, and not multi-platform.