[wlamartin]

I think this is a pretty poor understanding of the vulnerability. Yes, runc was split out from Docker but it now is maintained by many companies, including Red Hat - so to suggest that Docker software was "so terrible" doesn't sit right.

Not to mention that this is a fairly gnarly CVE - a great catch by SUSE and Docker - and claiming the software is terrible because it contained this seems like a real stretch.

[true_religion]

I'm not saying Docker is bad, only that having a Docker engineer come out and say 'no our bug wasn't fixed yet' shouldn't be the start of a confrontation.

[shykes]

It's not infrequent to see occasional tension between vendors around the wording and timing of security disclosures. There are frequent examples of this with Google's Project Zero for example.

As far as disagreements on the best way to handle a security disclosure, this one is pretty straightforward and was entirely avoidable. The vulnerability in question is a runC vulnerability, it affects equally all products with a dependency on runC (not just Docker). The vulnerability had already been patched in runC, and an update to Docker had already been released and announced. So it was not a zero day. A few vendors (not just Red Hat) have incorrectly announced to their users that they didn't need to upgrade to the latest version of Docker because their enterprise-grade commercial platform would "stop the vulnerability cold". In the case of Red Hat, the commercial differentiator is what they call "security-enhanced Linux" using SELinux.

These vendors are under a lot of pressure to justify the high cost of their enterprise subscription by demonstrating concrete value. A great way to do that is to describe a scary vulnerability in a well-known product like Docker, and show that buying their product is the best protection against it. That is why the article talks about a "Docker vulnerability" instead of a "runC vulnerability" - Docker is a better-known product so the story will be more impactful that way. And it's also why the vulnerability is qualified as a "zero-day" even though it wasn't: it makes the vulnerability scarier.

Red Hat was privately contacted to inform them of their mistake. They privately acknowledged the mistake. When the article hit the Hacker News front page, they were again privately informed of that as well. In spite of multiple requests, after several days they have still not corrected the article. This puts the security of Red Hat users at risk by continuing to tell them that an upgrade to Docker 1.12.6 is not necessary. This is especially disappointing because of the obvious conflict of interest. It was a perfect opportunity for Red Hat to set the bar high for themselves and remove any doubts that they might put the security of their users before commercial interest.

The saddest part is that RHEL and SELinux have genuine security benefits that could be explained in very compelling ways without these shady marketing tactics.

[sply]

BTW, can you confirm than SELinux in enforcing mode really prevents exploiting of this runC vulnerability? Therefore, the argue on the post's correctness considers only RadHat's marketing war.

Because if the answer is "No", and there's some other way to bypass SELinux and exploit this bug, it raises more grave accusation of RedHad - false statement about the vulnerability workaround.

[sply]

Thank you for clarification of your point. It really shows perfect example of the Red Hat marketing.

Can you please give a link to the announce from Red Hat or someone else urging their users that they don't need to upgrade? It would be the last thing closing the question.

[shykes]

The blog post being discussed here is the latest example. NOTE: the blog post has since been updated without acknowledging the inaccuracies in the earlier version.

[sply]

Just for history:

First post saved by archive.org: http://web.archive.org/web/20170114090437/http://rhelblog.re... Latest post: http://web.archive.org/web/20170117054512/http://rhelblog.re...

  $ wdiff -n -3 first latest
  
  ======================================================================
  [-Docker 0-Day Stopped Cold by-] SELinux
  ======================================================================
   SELinux {+Mitigates docker exec Vulnerability+}
  ======================================================================
   Fixed packages [-have been-] {+are being+} prepared and shipped for RHEL
  ======================================================================
   [-Centos.-] {+CentOS.+}
  ======================================================================
  
  
  
  [-Stopping 0-Days with-] SELinux
  ======================================================================
   SELinux {+Reduces Vulnerability+}
  ======================================================================
  
  
  [-How about a more visually enticing demo? Check out this animation:-]
  ======================================================================
   we were glad to see that our customers were [-safe-] {+safer+} if running containers with setenforce 1
  ======================================================================
   {+Even with SELinux in enforcement, select information could be leaked, so it is recommended that users patch to fully remediate the issue.+}
  {++}
  {+This post has been updated to better reflect SELinux’s impact on the Docker exec vulnerability and the changing threat landscape facing Linux containers.+}
  ======================================================================

I'm not sure that first post's version can be considered as recommendation to not upgrade. It just shows how RedHat people was happy to see that bug was prevented by another subsystem. Me, as a sysadmin, would be happy to to know that I'm not obligated to upgrade urgently everything I have. For most sysadmins it can be considered as a workaround, already engaged.

You as a Docker developer see the post as an attack on your project. But most of sysadmins and kernel developers see it as a nice example of the fruits of invisible long work - when well cared system with accurately configured security restrictions saves from some vulnerabilities.

Anyway, it not means underestimation of the Docker and you great job. Sorry you've got stressed by all this noise.