[FIX planned in 6.2] Docker

[NAS]

https://www.docker.com/docker-cve-database

 

CVE-2014-8178 and CVE-2014-8179 were released 2015-10-12 which is before unRAID Version 6.1.4 2015-11-15 and after Version 6.1.3 2015-09-20.

 

It may be that unRAIDs version of docker (1.7.1 - five version behind current 1.9.1) is unaffected by these vulnerabilities or that patches were cherry picked.

 

Since it is core and unpatchable by the user for clarity's sake can we confirm either these specific CVEs or our general docker security policy.

 

I suspect they were just missed since docker sees so few issues but conversely if we are not routinely updating docker we need to put it on the monitor list

[jonp]

A quick search on the CVE in Google gives you all the info you need.  Redhat even says they will not fix for these. They are both marked low risk.

[NAS]

I dont think it is elegant to ask every user to "search on the CVE in Google gives you all the info you need". I also pretty sure even if they did most of them would not understand the results.

 

Better we just do it once and if we are accepting the risk for them (i.e. deciding they cant be breached as it is not relevant to unRAID then tell them in language all can understand in the version release notes).

 

Personally I am off the opinion that there is no point ever accepting any risk and we should patch, just as we have been doing so well recently. i.e. we patched PHP even before Slackware did

[NAS]

unRAID update: Version 6.1.5 2015-11-30

 

It looks like docker remains "1.7.1 (2015-07-14)"

 

Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d4
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d4
OS/Arch (server): linux/amd64

 

Can you confirm closure of CVE-2014-8178 and CVE-2014-8179 from 1.8.3 (2015-10-12).

 

Also of note 1.9.0 (2015-11-03) contains the following security changes:

 

    Add SELinux profiles to the rpm package (#15832)

    Fix various issues with AppArmor profiles provided in the deb package (#14609)

    Add AppArmor policy that prevents writing to /proc (#15571)

 

[jonp]

I dont think it is elegant to ask every user to "search on the CVE in Google gives you all the info you need". I also pretty sure even if they did most of them would not understand the results.

 

Better we just do it once and if we are accepting the risk for them (i.e. deciding they cant be breached as it is not relevant to unRAID then tell them in language all can understand in the version release notes).

 

Personally I am off the opinion that there is no point ever accepting any risk and we should patch, just as we have been doing so well recently. i.e. we patched PHP even before Slackware did

It's easy to have that opinion when you don't need to perform the work to do what you want.  :-)

 

Folks trust us that if there is a major security hole, we will address it.  Commenting on every CVE that has not been addressed in unRAID is just not something we are going to do at this time. It is a major time sink and distraction from far greater benefits to our users like fixing bugs, adding features, and providing support.

[NAS]

It's easy to have that opinion when you don't need to perform the work to do what you want.  :-)

 

To be fair that is a cheap shot against someone who is just trying to help in the face of constant pushback.

 

Folks trust us that if there is a major security hole, we will address it.

 

Typically that is not how security patches are deployed as this approach means that when a serious security hole is announced the requirements to deploy an urgent patch also inflicts a massive simultaneous version bump and backlog of security patches on your users

 

There is obviously no necessity to do it this way but equally the approach you are adopting is as far as I can tell unique and with no patching policy to refer to people are left guessing exactly what it is.

 

Commenting on every CVE that has not been addressed in unRAID is just not something we are going to do at this time. It is a major time sink and distraction from far greater benefits to our users like fixing bugs, adding features, and providing support.

 

Like it or not it is our burden to comment on ALL upstream CVEs against code shipped by the OS. This is doubly true if we choose not to deploy them and offer the user no means to do so independently.

 

Security is security, it is not optional and certainly it is disappointing to see "adding features" as a justification for not deploying security fixes already packaged for deployment for us upstream.

 

It is proving thoroughly unpleasant doing so but if I see security issues that remain un-pacthed or undocumented beyond a stable version border I will continue post about them so that the community can make an informed choice.

[jonp]

We have different opinions on what is and isn't required of us. And to be fair, this isn't new. Things have been like this for a while and we have substantially improved patching since v5.  You don't have to like our stance or even agree with it, but I don't think it's too much to ask that you respect our decision.

 

Feel free to continue posting CVEs here. For those that are worried, they can search the CVE on Google to get more insight or trust us that we will patch critical issues as necessary. If a CVE is published that we feel is important enough to issue an announcement against, we will.

 

And if security patching is not optional, then why does "won't fix" exist for countless security patches in numerous OSes?  Because those OS vendors decided that the security issue in question wasn't important enough to address and/or did not represent a real threat to their users.

 

[NAS]

To be honest I think you are spending more time here than is required to actually fix.

 

For example:

 

If you have ascertained the two CVE are not required then it is perfectly acceptable to add this to your change log

 

[DOCKER SECURITY] CVE-2014-8178 and CVE-2014-8179. Not relevant or obscure, deferred.

 

There is no magic here. Here is a sample policy based on what I think your approach is almost:

 

"Important issues are patched immediately, less critical but still serious issues are deferred to next stable. Irrelevant or low priority issues are documented "somewhere official" and then deferred to next daemon upgrade".

 

But for goodness sake stop telling people they need to hit google and expect them even to know what it returns to save on this trivial burden.

 

There really is no need to be so confrontational on all things security. Its just a thing we need to find a way to deal with.

[NAS]

I understand docker is not going to be patched but for the sake of completeness I will continue to track security here so it is all in one place.

 

unRAID 6.1.6

 

Client version: 1.7.1

Client API version: 1.19

Go version (client): go1.4.2

Git commit (client): 786b29d4

OS/Arch (client): linux/amd64

Server version: 1.7.1

Server API version: 1.19

Go version (server): go1.4.2

Git commit (server): 786b29d4

OS/Arch (server): linux/amd64

 

Docker current stable

 

1.9.1 (2015-11-21

 

No new security fixes since 1.9.0 (2015-11-03)

[NAS]

Found this in another random docker thread. Updating title here.

 

The current release of unRAID is still using docker 1.7.1 which doesn't have compose. This will be rectified in 6.2, ...