Container hardening about dangerzone HOT 8 CLOSED

I personally use --selinux-enabled --no-new-privileges --seccomp-profile /etc/docker/default.json with moby's default profile but in your case you likely want something a bit more refined.

Bear in mind with the Docker runtime you might also leverage its command-line arguments for both DNS request filtering and/or IP isolation.

from dangerzone.

I personally use --selinux-enabled --no-new-privileges --seccomp-profile /etc/docker/default.json with moby's default profile but in your case you likely want something a bit more refined.

I'm not sure when those options were introduced, but they don't seem to work with Docker in Debian stable:

$ DOCKER_HARDENING="--network none --selinux-enabled --no-new-privileges --seccomp-profile /etc/docker/default.json"
$ docker run $DOCKER_HARDENING -v $PIXEL_DIR:/tmp/ -v ~/Downloads/CV.pdf:/tmp/inputfile flmcode/dangerzone document-to-pixels
unknown flag: --selinux-enabled
See 'docker run --help'.
$ docker version
Client:
 Version:           18.09.1
 API version:       1.39
 Go version:        go1.11.6
 Git commit:        4c52b90
 Built:             Sun, 21 Feb 2021 18:18:35 +0100
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11.6
  Git commit:       4c52b90
  Built:            Sun Feb 21 17:18:35 2021
  OS/Arch:          linux/amd64
  Experimental:     false

... something to keep in mind if you add such new flags...

Here it seems the following works: --network none --security-opt=no-new-privileges:true. The documentation also seems to say that there is a seccomp profile in Docker by default now...

from dangerzone.

i started hacking at the Dockerfile to make it a little more sane (ie. not run as root by default). It's not done, after reading moby/moby#2259, i think the right way forward is to just access the input file readonly, and extract the files out of the container with docker cp instead of having a shared, writable filesystem, because that basically requires root, either inside of the container (current approach) or outside (approach suggested in firstlookmedia/dangerzone-converter#7)

from dangerzone.

update: i have a prototype in the docker image repo that does exactly that, remaining work is to port the frontend to this method, see https://github.com/firstlookmedia/dangerzone-converter/blob/59b49a49a5b7ca2d9a80f12db6cdee3ec4c16477/batch-convert.py

from dangerzone.

i think the right way forward is to just access the input file readonly, and extract the files out of the container with docker cp instead of having a shared.

Note that this will leave behind stopped containers which contain potentially sensitive documents. I'd suggest to use the --rm flag in order to cleanup the container after each run.

from dangerzone.

from dangerzone.

Oh, in that case I probably was looking in the wrong corner. container.py in master does not seem to cleanup after itself, though.

from dangerzone.

from dangerzone.