4 ms·

You cannot (repeat: cannot) sign Docker containers any other way, so it's barely a half feature and does not work for enterprises at all. What makes you think

by bigmac 10y ago

You cannot (repeat: cannot) sign Docker containers any other way, so it's barely a half feature and does not work for enterprises at all. What makes you think this? It is 100%, patently false. Private notary servers can be deployed alongside private registry servers without problem. See here for docs on how to do it: https://github.com/docker/notary/blob/master/docs/running_a_service.md https://github.com/docker/notary/blob/master/docs/running_a_...

jsmthrowaway 10y ago
> What makes you think this? The docs I linked and quoted, written by your own organization and helpfully pasted into the point I made? I'm glad to see it's possible (if cumbersome), but I ruled Docker out for this purpose based on the exact link I just pasted. I also followed up and didn't see a "hey, you can sign private registries" bullet in your blog post responding to this paper, or much of anywhere, and Googling "docker sign private registries" doesn't go anywhere. I'm still unsure why I'd stand up several daemons to accomplish signing a file, but that's a side point. ---- ETA: I can no longer reply because I've burned my precious HN comment budget commenting upon this paper (sorry, blame HN), so here's what I would reply to you downthread: > 1. We have to host the signatures somewhere, so we host them in a store we call the notary server. We've had this solved for a long time with .asc files, and Docker is already shipping an HTTP server or six. Shit, extend the Docker format and put the signature on each layer. There's a lot of prior art from RPM and dpkg in particular on how this can be done without writing yet another Docker daemon to run. I'm sorry, I have to call bullshit, here. Docker is a very strong daemon-for-everything engineering culture, and that's the only reason it exists. It's also why folks are competing with you, because there are three or four different daemons in the Docker ecosystem that simply should not exist. Including dockerd. > Think serving an outdated container with known-vulnerable software. Sadly, most artifact signing systems do not mitigate this attack today, Because it's out of scope of a signature. That is conflating a signature with content revocation, which is a different problem altogether. A signature is an attestation of certain properties of data, and "is no longer valid content because circumstances changed after it was signed" is not one of them. The validity of the content is orthogonal to its signature. That known-vulnerable container is still a valid signature, and it's overreaching to expect a signature system to solve that problem. That is solvable in other ways. Known-bad OpenSSL is still signed in repositories. And valid. And that's fine, because it's a separation of concerns; you get non-repudiation, integrity, all that stuff from a signature scheme. Upgrading to gatekeeping content on top of signatures indicates to me a fundamental misunderstanding of the problem ("can I run this?" instead of "this is an authenticated, intact image that came from where I expect"), which concerns me. You can solve the problem you present in other ways. Mixing in the term "replay attack" is extremely confusing and I think diluting your point, because it is baffling me and really does not apply to what you are saying.
- bigmac 10y ago
  Sorry about that; I will get that page of the docs fixed. Open invitation to anyone here: Our implementation of TUF via notary has been serving us well. If you decide to try it out and run in to any snags let me know and I can help you with getting it up and running. Contact info can be found in my profile.
- bigmac 10y ago
  The several daemons serve two purposes: 1. We have to host the signatures somewhere, so we host them in a store we call the notary server. 2. Notary has a concept of timestamping, so we spin up a timestamping server alongside a notary server that can guarantee the freshness of the data. We use a separate server so that folks can segment the timestamp signing functionality from the signature metadata serving functionality. This helps allow separation of concerns. Timestamping is important because it can help prevent replay attacks where old, validly signed data is served to clients. Think serving an outdated container with known-vulnerable software. Sadly, most artifact signing systems do not mitigate this attack today, but we wanted to make sure ours would.
- bigmac 10y ago
  Responding to your edit: Notary, the underlying project that implements Docker's Content Trust feature, is an implementation of The Update Framework (TUF). Generally, you want a software update system to deal with a whole host of issues. Just solving "is this content signed" actually achieves very little. Survivable key compromise, freshness guarantees, resilience against mix-and-match attacks are all critical to building a system that actually meets real-world use cases and attacks. Threshold signing and signing delegation are additional features that you get when using TUF, which help with splitting the ability to sign across multiple individuals or systems. You seem to be interested in this topic. I recommend you read a couple of papers to get some more background on why TUF exists and what problems it solves. A key point would be to understand why TUF deals with signed collections of software instead of just individual signed objects. Start here to get an overview of The Update Framework: 1. Overview: https://theupdateframework.github.io/ https://theupdateframework.github.io/ 2. Specification: https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt https://github.com/theupdateframework/tuf/blob/develop/docs/... Existing package managers and their shortcomings are covered in these two papers: 1. https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.p... 2. https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p...

by bigmac 10y ago

jsmthrowaway 10y ago

> What makes you think this? The docs I linked and quoted, written by your own organization and helpfully pasted into the point I made? I'm glad to see it's possible (if cumbersome), but I ruled Docker out for this purpose based on the exact link I just pasted. I also followed up and didn't see a "hey, you can sign private registries" bullet in your blog post responding to this paper, or much of anywhere, and Googling "docker sign private registries" doesn't go anywhere. I'm still unsure why I'd stand up several daemons to accomplish signing a file, but that's a side point. ---- ETA: I can no longer reply because I've burned my precious HN comment budget commenting upon this paper (sorry, blame HN), so here's what I would reply to you downthread: > 1. We have to host the signatures somewhere, so we host them in a store we call the notary server. We've had this solved for a long time with .asc files, and Docker is already shipping an HTTP server or six. Shit, extend the Docker format and put the signature on each layer. There's a lot of prior art from RPM and dpkg in particular on how this can be done without writing yet another Docker daemon to run. I'm sorry, I have to call bullshit, here. Docker is a very strong daemon-for-everything engineering culture, and that's the only reason it exists. It's also why folks are competing with you, because there are three or four different daemons in the Docker ecosystem that simply should not exist. Including dockerd. > Think serving an outdated container with known-vulnerable software. Sadly, most artifact signing systems do not mitigate this attack today, Because it's out of scope of a signature. That is conflating a signature with content revocation, which is a different problem altogether. A signature is an attestation of certain properties of data, and "is no longer valid content because circumstances changed after it was signed" is not one of them. The validity of the content is orthogonal to its signature. That known-vulnerable container is still a valid signature, and it's overreaching to expect a signature system to solve that problem. That is solvable in other ways. Known-bad OpenSSL is still signed in repositories. And valid. And that's fine, because it's a separation of concerns; you get non-repudiation, integrity, all that stuff from a signature scheme. Upgrading to gatekeeping content on top of signatures indicates to me a fundamental misunderstanding of the problem ("can I run this?" instead of "this is an authenticated, intact image that came from where I expect"), which concerns me. You can solve the problem you present in other ways. Mixing in the term "replay attack" is extremely confusing and I think diluting your point, because it is baffling me and really does not apply to what you are saying.

bigmac 10y ago
Sorry about that; I will get that page of the docs fixed. Open invitation to anyone here: Our implementation of TUF via notary has been serving us well. If you decide to try it out and run in to any snags let me know and I can help you with getting it up and running. Contact info can be found in my profile.
bigmac 10y ago
The several daemons serve two purposes: 1. We have to host the signatures somewhere, so we host them in a store we call the notary server. 2. Notary has a concept of timestamping, so we spin up a timestamping server alongside a notary server that can guarantee the freshness of the data. We use a separate server so that folks can segment the timestamp signing functionality from the signature metadata serving functionality. This helps allow separation of concerns. Timestamping is important because it can help prevent replay attacks where old, validly signed data is served to clients. Think serving an outdated container with known-vulnerable software. Sadly, most artifact signing systems do not mitigate this attack today, but we wanted to make sure ours would.
bigmac 10y ago
Responding to your edit: Notary, the underlying project that implements Docker's Content Trust feature, is an implementation of The Update Framework (TUF). Generally, you want a software update system to deal with a whole host of issues. Just solving "is this content signed" actually achieves very little. Survivable key compromise, freshness guarantees, resilience against mix-and-match attacks are all critical to building a system that actually meets real-world use cases and attacks. Threshold signing and signing delegation are additional features that you get when using TUF, which help with splitting the ability to sign across multiple individuals or systems. You seem to be interested in this topic. I recommend you read a couple of papers to get some more background on why TUF exists and what problems it solves. A key point would be to understand why TUF deals with signed collections of software instead of just individual signed objects. Start here to get an overview of The Update Framework: 1. Overview: https://theupdateframework.github.io/ https://theupdateframework.github.io/ 2. Specification: https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt https://github.com/theupdateframework/tuf/blob/develop/docs/... Existing package managers and their shortcomings are covered in these two papers: 1. https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.p... 2. https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p...