Run agent scanner components in separate docker containers

[ajacques]

Is your feature request related to a problem?
Issues with the existing solution of running everything in a single container:

1. Zombie processes don't get cleaned up (e.g. Chromium-browse not being cleaned up properly after a screenshot #302)
2. The natlas/agent Docker image is large with all of the scanners built in. Thus we're forcing consumers to download large images
3. Everything gets run in a single container and the same security context/namespace

Describe the feature you'd like
We could run the agent scanning components in separate Docker containers with separate images. The Natlas agent would bind mount the docker.sock into the container, then use the Docker API to orchestrate the worker containers and cleanup after it's done.

Have you considered alternative ways to get this feature

Additional context
Add any other context or screenshots about the feature request here.

[0xdade]

The primary concern with this idea is that the agent container (which handles communication with the server and orchestration of the sub-components) now can control the entire docker api, which is not really ideal for security. But it also means that the agent is in a higher trust zone because that container isn't actually communicating with anything directly. For example, a chrome 0day right now could result in the entire agent container being compromised. By putting subcomponents in different containers that are launched on demand, this would definitely increase the boundaries.

How do we (safely) move files between containers? We don't just read stdout from nmap, we read the .nmap .xml and .gnmap files. We read the images and json produced by aquatone (and even when we bypass aquatone we'll still need to be able to read the images produced by chrome). Most tools that we might want to include are likely to produce file outputs that we'll want to consume. So do we need to have a shared volume between the orchestrating container and all it's children containers?

[ajacques]

Agreed on the security aspects. I won't downplay those. There appear to be some players that perform ACL on the Docker API:

• https://scene-si.org/2016/04/25/exposing-your-docker-api/
• https://docs.docker.com/engine/extend/plugins_authorization/

Options for moving files between containers:

1. A shared volume. We can then mount a scan-tool specific folder into the scanner container
2. Serialized across stdout/stderr. Everything can technically be serialized across stdout. I don't necessarily like serializing an image across stdout as base64, but it technically would work.

[0xdade]

Heh, we do already base64 the images as part of the blob across the wire so that everything needed for a scan to be processed is included in a single POST request (this has caused issues with nginx's client_max_body_size before and isn't entirely idea). Shared volumes is probably the preferred approach if we do go this way.