Hello, I'm the lead security engineer at Docker, Inc.
There is nothing particularly new in Jonathan's post and I thank him for facilitating a conversation. Image security is of the upmost importance to us. For these reasons, we've concentrated efforts here in both auditing and engineering effort. Engineers here at Docker, our auditors, and community contributors alike have been evaluating this code to many of the same conclusions.
Last month, we released Docker 1.3.2 which included limited privilege separation and extending this paradigm has been discussed. I have explicitly called out the need for containerization of the 'xz' process, and to run it in an unprivileged context. I thank Jonathan for reminding us of the need for this work and validating much of what is already in progress.
As the recently published CVEs describe, we are expending resources in discovering and fixing security issues in Docker. Yet, I agree the v1 registry has a flawed design and we're aware of it. In September, I requested to become a maintainer of the tarsum code and have also made proposals and pushed PRs toward improving the v1 registry integration. This is not to replace the v2 effort, but to offer improved security for the design we have today.
We have a draft for a v2 registry and image format. This and the supporting libtrust library are in the process of being audited by a 3rd-party. This is something we had previously promised the community and are making good on. What code exists today is a technical preview.
Unlike the v1 registry and image format, the libtrust and v2 image format code has been designed for a decentralized model. However, as the libtrust and v2 image work, and subsequently, registry protocols are still in draft and security review, it is difficult for us to recommend that users yet attempt deploying these. This is why the developers of that code have not published clear instructions for its use, nor made such recommendations. As this work comes out of review and a specification is finalized, we should expect to see a much better experience and more secure image transport, along with stronger support for on-premises and 3rd-party registries.
> There is nothing particularly new in Jonathan's post and I thank him for facilitating a conversation.
Maybe not new to you or Docker Inc staff, but I don't see any warnings that a pull could result in complete compromise. On top of this, the inaccurate "verified" image message is still in the current release.
> I have explicitly called out the need for containerization of the 'xz' process, and to run it in an unprivileged context.
Do you have a link to this?
> As this work comes out of review and a specification is finalized, we should expect to see a much better experience and more secure image transport
Is there a draft specification available for libtrust?
> However, as the libtrust and v2 image work, and subsequently, registry protocols are still in draft and security review, it is difficult for us to recommend that users yet attempt deploying these.
> I don't see any warnings that a pull could result in complete compromise
Well, certainly not by intention, but we did have CVEs issued with 1.3.3 and 1.3.2 which indicated that pulls were not secure. They're better now. Perfect? No, it does seem to be far better. I also put together a PoC of containerizing the entire 'docker pull' process and I'd like to see such privilege separation in the future. (https://github.com/ewindisch/docker-pull)
> the "verified" image message is still in the current release.
I agree the "verified" image message is too strongly worded and this is what bug reports are for. Solomon seems to agree as well.
This is a valid criticism. I'll admit this code did not get the proper review and audit that I personally expected before being deployed. At Docker, we consider that a process bug. Things happen, we learn, we adapt. We didn't pull the code, but neither did we advise anyone else yet deploy a v2 server. Again, we have an active audit against this code currently, and the spec is developing.
>However, as the libtrust and v2 image work, and subsequently, registry protocols are still in draft and security review, it is difficult for us to recommend that users yet attempt deploying these.
I am not sure I agree with this. You have deployed these draft protocols in 1.3 resulting in CVEs for the pull ops. For me (and I think for every software release engineer), I would deploy something only as part of a test branch and not as part of production code. This is (IMHO) bad engineering practice for such a vital piece of software. Not good.
It's unfortunate ewindisch's post has elicited such a response. He clearly spent time trying to communicate clearly the situation at Docker and some of the security issues surrounding it. I could be wrong but it doesn't seem that you've spent a commensurate amount of time and through in your reply.
It's certainly your right to be snarky and negative. Perhaps that's how you've learned to address others whom you're offended by. But instead of insulting ewindisch by using 'marketing' as an epithet, can I encourage you to address the content of the post instead?
Clearly, by using the term 'marketing' you mean to imply that the content of ewindisch's post lacks the kind of content you deem relevant to sufficiently addressing this issue. Why don't you challenge ewindisch on this? That would be more constructive than saying that he's NOT the lead security engineer.
Perhaps it has something to do with smaller companies and the need for engineers to talk to customers. But the engineers I work with would never say silly things like "facilitating a conversation." OTOH, the marketing department will go to great lengths to add phrases like that to anything they send outside the company.
I've seen more authentic replies on here get lambasted for being unprofessional. That bit of phrasing did make me twitch, but I can see how he might've thought he needed to put on his 'corporate communications' voice before posting here.
Much defensive. Its easier to look at what things are rather than taking it personally:
The engineer tries to downplay the issue by the now conventional "we're working on fixing it". And the whole pr-approved speech.
What should be fixed is the whole process and design reasons why this is even allowed to happen.
It's not the fault of the engineer - but by being the messenger in this case you're also condoning it. And downplaying stuff on non-technical grounds, that's actually marketing. But it's easier to be offended than to realize that these days.
There is nothing particularly new in Jonathan's post and I thank him for facilitating a conversation. Image security is of the upmost importance to us. For these reasons, we've concentrated efforts here in both auditing and engineering effort. Engineers here at Docker, our auditors, and community contributors alike have been evaluating this code to many of the same conclusions.
Last month, we released Docker 1.3.2 which included limited privilege separation and extending this paradigm has been discussed. I have explicitly called out the need for containerization of the 'xz' process, and to run it in an unprivileged context. I thank Jonathan for reminding us of the need for this work and validating much of what is already in progress.
As the recently published CVEs describe, we are expending resources in discovering and fixing security issues in Docker. Yet, I agree the v1 registry has a flawed design and we're aware of it. In September, I requested to become a maintainer of the tarsum code and have also made proposals and pushed PRs toward improving the v1 registry integration. This is not to replace the v2 effort, but to offer improved security for the design we have today.
We have a draft for a v2 registry and image format. This and the supporting libtrust library are in the process of being audited by a 3rd-party. This is something we had previously promised the community and are making good on. What code exists today is a technical preview.
Unlike the v1 registry and image format, the libtrust and v2 image format code has been designed for a decentralized model. However, as the libtrust and v2 image work, and subsequently, registry protocols are still in draft and security review, it is difficult for us to recommend that users yet attempt deploying these. This is why the developers of that code have not published clear instructions for its use, nor made such recommendations. As this work comes out of review and a specification is finalized, we should expect to see a much better experience and more secure image transport, along with stronger support for on-premises and 3rd-party registries.