> 1. The size of the docker images. The debian base image is > 100MB.
> Downloading this would increase both the service installation time and
> the requirements on the system's RAM.
This problem can easily be circumvented by using alpine based images:
the alpine base image itself is around 4mb and many packages already
exist for alpine based systems for this reason.
For those that do not exist I agree that the whole repackaging process
could be a pain AND involve a security risk (one would need to be able
to audit the whole process and ascertain that the repackaged application
has not been modified in any way)
> 2. The lack of trustworthy sources. For many services there are "public"
> images available, which, IIUC, can be created and maintained by anyone.
https://docs.docker.com/engine/security/trust/content_trust/#content-trust-operations-and-keys
outlines the way the docker developers envisioned their image trust model.
Since docker images uses a pretty standard key hierarchy scheme (offline
root key and repository tagging keys to sign tags) it shouldn't be hard
to verify the signatures of every image that is downloaded and only run
those that have a verifiable chain of trust.
I can see two ways to do this:
1. Trust everyone that sign and warn the user every time the certificate
chain does not have a Tails signing key in it. Double warning (or demand
a specific manipulation a la persistent packages) to run an unsigned image.
2. Set up a linux tails registry containing audited and signed base
images to build from as well as pre-built, audited and signed service
images.
Obviously one could mix the two approaches, but neither would be too
much work since it seems the crypto infrastructure is already in place
on docker's side.
Now there might be another issue: privileged containers. As you probably
know, some containers require some privileges to work (such as changing
the default route, or accessing specific devices on the host). This
could prove to be a huge security risk if not handled correctly.
If the docker daemon is properly configured (unable to modify the
firewall rules) leaks from containers are less likely, but the other
privileges such as access to host devices still remains and has to be
dealt with one way or another.
Regards,
