

Introducing Docker Content Trust - dkasper
https://blog.docker.com/2015/08/content-trust-docker-1-8/

======
moviuro
I don't get the point of creating yet another signing framework. Integrating
GnuPG would have saved them time and money. Also, it is used on virtually any
linux distro package manager (which is about just a bit more critical than
docker)...

Perhaps I missed something though? ([https://www.youtube.com/watch?v=at72dhg-
SZY&feature=youtu.be...](https://www.youtube.com/watch?v=at72dhg-
SZY&feature=youtu.be&t=4873))

~~~
bigmac
This integration is built on The Update Framework, which has some distinct
advantages over GPG's model.

First, TUF allows you to have freshness guarantees over the content. In GPG's
model a MITM or malicious mirror can serve you old, known vulnerable content
that you'll accept as valid because the signatures verify. This is not
possible with TUF as metadata is additionally signed with a timestamping key.

Second, TUF has a property called 'survivable key compromise' which basically
means that there are a hierarchy of keys involved in the system, each with a
different responsibility and security requirements. There's a root key that's
kept offline, a target key responsible for signing actual content, a
timestamping key for freshness, and a snapshot key to tie all the other keys
together. GPG's model does allow for signing subkeys, but it is rather clunky
to use and many of the Linux package managers don't support using signing
subkeys, sadly.

Finally, GPG's usability leaves something to be desired. Docker makes pushing
and pulling of images extremely easy, essentially making everyone a publisher
of content. GPG works when publishing software is more rare and you can take
the time to use a new utility in order to get security guarantees, but we
wanted to make it extremely easy so that anyone can do it.

For more background, this paper does a good survey of existing package
managers and where they fall short:
[https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.p...](https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf)

~~~
moviuro
> Finally, GPG's usability leaves something to be desired. Docker makes
> pushing and pulling of images extremely easy, essentially making everyone a
> publisher of content. GPG works when publishing software is more rare and
> you can take the time to use a new utility in order to get security
> guarantees, but we wanted to make it extremely easy so that anyone can do
> it.

A wrapper would have done an awesome job at that... I use GnuPG daily, enter a
passphrase once and boom. Mails are signed, my password manager unlocked.
Where is the "unusability" in this?

~~~
bigmac
You're right, wrappers can abstract away complexity. That's effectively what
TUF is: a wrapper framework around low level crypto primitives that achieves a
secure content distribution system. GPG alone would not have given sufficient
guarantees around freshness and survivable key compromise.

TUF should be understood as a higher level concept than GPG. There are
additional features of the TUF spec that we'll be implementing in later
versions, such as threshold signing (k of n signatures required for
verification) and secure delegation.

For what its worth, TUF could be implemented on top of GPG just fine. If folks
have an appetite for that we'd welcome contributions here:
[https://github.com/docker/notary](https://github.com/docker/notary)

------
skj
I don't understand why we don't make the container ID a hash of the image
contents, have the docker CLI verify it, and let people use conventional means
to trustedly pass around the correct container ID.

This seems like a lot of extra infrastructure and process in a space where
there is already a lot of infrastructure and process.

~~~
robryk
In that case updating a container to a new version would require everyone to
change the container ID they are using. This introduces friction that either
causes people not to update, or to develop wrappers that do something similar
to this.

Granted, this doesn't always apply to packages you build yourself.

~~~
skj
Having signed images to allow trust does seem valuable, but easily verifiable
images, without the need for crypto, seems like a more fundamental building
block upon which more complex processes can be built.

~~~
shykes
You are right, they are not mutually exclusive, and we are working on both in
parallel. We are working on specifying a standardized way to 1) hash a
container in its runnable form, and 2) attach arbitrary signatures constructed
from that hash. That will allow using your favorite existing tools (eg. gpg)
to create arbitrary trust and verification systems. This is part of the OCP
project, and will be implemented by RunC which we donated last month. See
[https://github.com/opencontainers/runc](https://github.com/opencontainers/runc)
and
[https://github.com/opencontainers/specs](https://github.com/opencontainers/specs)
.

As a rule of thumb, end-to-end trust and naming is most useful to developers
("How do I know I'm building on the right dependency, and using the latest and
most secure version?"), and low-level hashing is most useful to ops ("How do I
enforce a whitelist of containers allowed on my production cluster based on
home-made PKI and policies?")

Another distinction is that you can use Notary (and Docker Trusted Content)
with any kind of content - for example Compose files, source artifacts, system
packages used to build the container, etc.

------
mrfusion
Would docker make a good sandbox or can applications break out?

~~~
davexunit
It makes a good sandbox because it uses a chroot/pivot_root + unshares
pid/net/uts/mnt/ipc namespaces, but it doesn't use user namespaces so root in
the container is root on the host which is a bit scary.

~~~
mrfusion
Thanks. Have there been documented breakouts or it more theoretical?

~~~
eropple
Not in recent versions.

~~~
kentonv
[http://www.openwall.com/lists/oss-
security/2015/07/22/7](http://www.openwall.com/lists/oss-
security/2015/07/22/7) is three weeks old and would allow breaking out of
Docker. Bugs like this (in Linux) are found regularly.

