6 ms·

Introducing Docker Content Trust

101 points by dkasper 11y ago

moviuro 11y ago
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&t=4873 https://www.youtube.com/watch?v=at72dhg-SZY&feature=youtu.be...)
- bigmac 11y ago
  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.pdf https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.p...
  - kordless 11y ago
    > 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 presumes you use HTTP, have a compromised SSL cert, or have pissed off the NSA. At the worst one would be installing older packages with known vulnerabilities via a replay attack, not a fresh code injection by the attacker. This is more the fault of the package manager running over HTTP than GPG, as far as I can see. Here's a paper covering 'survivable key compromise' by the same chaps: http://freehaven.net/~arma/tuf-ccs2010.pdf http://freehaven.net/~arma/tuf-ccs2010.pdf. Interesting stuff.
    - dmcgowan 11y ago
      > This presumes you use HTTP, have a compromised SSL cert, or have pissed off the NSA. This is not taking into content mirroring. TUF allows you to treat all mirrors as potentially malicious allowing anyone to reliably deliver trusted content, even in an untrusted network. GPG does not provide a way to detect active attacks other than signature verification.
      - kordless 11y ago
        This is still an apples to oranges argument. GPG is a way to sign data in a trusted manner, including data that is delivered by both trusted and untrusted systems. If you want to point fingers, point at APT, YUM or RPM, not GPG.
  - moviuro 11y ago
    > 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?
- sciurus 11y ago
  They didn't, they used http://theupdateframework.com/ http://theupdateframework.com/ Python is also looking at using this for their package management system, pip. https://lwn.net/Articles/629426/ https://lwn.net/Articles/629426/
- ams6110 11y ago
  Signify[1] from OpenBSD is also extant, and somewhat lighter than GnuPG for this purpose. [1] Discussion: https://news.ycombinator.com/item?id=9708120 https://news.ycombinator.com/item?id=9708120
mrfusion 11y ago
Would docker make a good sandbox or can applications break out?
- davexunit 11y ago
  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.
  - bigmac 11y ago
    And user namespaces are really close to being merged: https://github.com/docker/docker/issues/15187 https://github.com/docker/docker/issues/15187
    - davexunit 11y ago
      Great!
  - mrfusion 11y ago
    Thanks. Have there been documented breakouts or it more theoretical?
    - eropple 11y ago
      Not in recent versions.
      - kentonv 11y ago
        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.
    - count 11y ago
      Even if the code can't break out, be aware of other issues of non-fully virtualized multi-tenancy: https://www.cs.unc.edu/~reiter/papers/2014/CCS1.pdf https://www.cs.unc.edu/~reiter/papers/2014/CCS1.pdf
skj 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.

101 points by dkasper 11y ago

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&t=4873 https://www.youtube.com/watch?v=at72dhg-SZY&feature=youtu.be...)

bigmac 11y ago
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.pdf https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.p...
- kordless 11y ago
  > 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 presumes you use HTTP, have a compromised SSL cert, or have pissed off the NSA. At the worst one would be installing older packages with known vulnerabilities via a replay attack, not a fresh code injection by the attacker. This is more the fault of the package manager running over HTTP than GPG, as far as I can see. Here's a paper covering 'survivable key compromise' by the same chaps: http://freehaven.net/~arma/tuf-ccs2010.pdf http://freehaven.net/~arma/tuf-ccs2010.pdf. Interesting stuff.
  - dmcgowan 11y ago
    > This presumes you use HTTP, have a compromised SSL cert, or have pissed off the NSA. This is not taking into content mirroring. TUF allows you to treat all mirrors as potentially malicious allowing anyone to reliably deliver trusted content, even in an untrusted network. GPG does not provide a way to detect active attacks other than signature verification.
    - kordless 11y ago
      This is still an apples to oranges argument. GPG is a way to sign data in a trusted manner, including data that is delivered by both trusted and untrusted systems. If you want to point fingers, point at APT, YUM or RPM, not GPG.
- moviuro 11y ago
  > 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?
sciurus 11y ago
They didn't, they used http://theupdateframework.com/ http://theupdateframework.com/ Python is also looking at using this for their package management system, pip. https://lwn.net/Articles/629426/ https://lwn.net/Articles/629426/
ams6110 11y ago
Signify[1] from OpenBSD is also extant, and somewhat lighter than GnuPG for this purpose. [1] Discussion: https://news.ycombinator.com/item?id=9708120 https://news.ycombinator.com/item?id=9708120

mrfusion 11y ago

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

davexunit 11y ago
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.
- bigmac 11y ago
  And user namespaces are really close to being merged: https://github.com/docker/docker/issues/15187 https://github.com/docker/docker/issues/15187
  - davexunit 11y ago
    Great!
- mrfusion 11y ago
  Thanks. Have there been documented breakouts or it more theoretical?
  - eropple 11y ago
    Not in recent versions.
    - kentonv 11y ago
      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.
  - count 11y ago
    Even if the code can't break out, be aware of other issues of non-fully virtualized multi-tenancy: https://www.cs.unc.edu/~reiter/papers/2014/CCS1.pdf https://www.cs.unc.edu/~reiter/papers/2014/CCS1.pdf

skj 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.