[jwildeboer]

When the top comment is a claim that we at Red Hat post incorrect information and that we at Red Hat are expected to delete said supposedly incorrect information without any technical explanation on why said information is incorrect, I do wonder who is the bully in your opinion.

I posted this entry and I work at Red Hat.

[shykes]

The post is in fact incorrect. The reason Nathan is not sharing more technical details is to protect the security of Red Hat users.

Also, if hypothetically the full details made Red Hat look bad, is it fair to assume you would be calling Nathan hostile for sharing them? In that scenario is there any course of action we could follow that would satisfy you?

[jwildeboer]

The article is about how SELinux helps in mitigating or even blocking paths that would lead to a working exploit.

The article explicitly states the CVE number and the fact that updated packages are available.

The article IMHO doesn't attack nor provoke Docker and its people. Yet the first comment posted here DOES contain direct accusations against Red Hat. I don't think that's helpful nor needed. That's all.

I still think that SELinux and Docker are a good combination and this article helps in understanding why.

[otterley]

The title of the article is "Docker 0-Day Stopped Cold by SELinux." The title strongly implies that SELinux would have prevented the issue in the CVE even without the fixes Docker provides.

Then the text of the article states:

"This CVE reports that if you exec'd into a running container, the processes inside of the container could attack the process that just entered the container. If this process had open file descriptors, the processes inside of the container could ptrace the new process and gain access to those file descriptors and read/write them, even potentially get access to the host network, or execute commands on the host. ... It could do that, if you aren’t using SELinux in enforcing mode."

So, not only does the title make this suggestion, but the text of the article downright says it.

If the claim is wrong, then Docker's security team is right to correct it. However, I think they should do so in a forum other than in the comments of a HN post, be thorough in their explanation, and maintain a professional, polished tone in any communications.

And, of course, Red Hat should correct and/or clarify the post as well.

[Rapzid]

Work with RedHat and let them issue a correction; HN seems like hardly the forum to be calling this out in such a manner. The fact that you even made the "bully" post leads me to believe that Docker views RedHat as a threat and their post promoting SELinux as an affront to Docker. I'd wager it didn't appear that way to the many individuals that understand both the benefits of systems like SELinux and AppArmour, as well as the difficulty in promoting them. Very interesting at the least; one could read a lot into that.

Honestly, Docker stepped in it here. This appears to be a theme, and with your posts in particular. I personally can't think of another project that causes more drama on HN.

[justincormack]

SELinux is great, and it somewhat mitigates this CVE, which is what defence in depth is indeed supposed to do. There is a big difference between "Docker 0-day stopped cold by SELinux" and "Runc CVE mitigated by SELinux" which is what a factual headline would be, as it is not a 0-day, and affects the majority of container runtimes (it was derived from an lxc CVE originally). You should always use defence in depth to make exploits harder, but you should always have the humility to understand that security is hard, and is an ongoing task to make every part of the system more secure, while keeping is usable.

[true_religion]

This drama is a bid... odd in tone to me. It feels as if theres a huge confrontation looming, where right now all Docker came out and said was "SE Linux only barely helped us, our software was actually so terrible that even with the best effort of SE Linux, it still was vulnerable".

This makes Docker look worse.

The only way SE Linux can look bad is if you were on the fence about its efficacy, and are only now hearing it can't even stop Docker's problems.

[digi_owl]

https://github.com/subuser-security/subuser/issues/216

"A number of developers from RedHat were once very involved in the project. However, these developers had a very arrogant attitude towards Docker: They wanted docker changed so that it would follow their design ideas for RHEL and systemd. They often made pull requests with poorly written and undocumented code and then they became very agressive when those pull requests were not accepted, saying "we need this change we will ship a patched version of Docker and cause you problems on RHEL if you don't make this change in master." They were arogant and agressive, when at the same time, they had the choice of working with the Docker developers and writting quality code that could actually be merged. Another thing they often said was along the lines of "systemd is THE ONE AND ONLY INIT SYSTEM so why do you care about writing code that might be portable?" Or "even though the universal method works with systemd now. A redesign has already been planned in systemd, so do it the new systemd way and don't be portable."(This is in response to the fact that Docker writes to cgroups, and systemd would like to be the "sole writter to cgroups" some time in the future.) I think everyone got fed up with those people, and Docker has rightly pushed them out."

[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.

[BeefySwain]

>The reason Nathan is not sharing more technical details is to protect the security of Red Hat users.

Security through obscurity?

[ceejayoz]

If you want to be that loose with the definition, passwords and private keys are "security through obscurity".

Giving people time to patch before releasing the details of how it can be exploited isn't a bad security practice.

[GranPC]

Responsible disclosure.

[madez]

Obscurity does add security. It might not stop an attacker, but probably slows him down. That delay is sometimes important to have.