6 ms·

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 informatio

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 10y ago
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 10y ago
  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 10y ago
    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.
- deleted 10y ago
  [deleted]
- BeefySwain 10y ago
  >The reason Nathan is not sharing more technical details is to protect the security of Red Hat users. Security through obscurity?
  - GranPC 10y ago
    Responsible disclosure.
  - ceejayoz 10y ago
    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.
  - madez 10y ago
    Obscurity does add security. It might not stop an attacker, but probably slows him down. That delay is sometimes important to have.
- Rapzid 10y ago
  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 10y ago
    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 10y ago
    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.
    - wlamartin 10y ago
      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.

shykes 10y ago

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 10y ago
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 10y ago
  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.
deleted 10y ago
[deleted]
BeefySwain 10y ago
>The reason Nathan is not sharing more technical details is to protect the security of Red Hat users. Security through obscurity?
- GranPC 10y ago
  Responsible disclosure.
- ceejayoz 10y ago
  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.
- madez 10y ago
  Obscurity does add security. It might not stop an attacker, but probably slows him down. That delay is sometimes important to have.
Rapzid 10y ago
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 10y ago
  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 10y ago
  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.
  - wlamartin 10y ago
    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.