Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

banyanops.com

Post reply on HN
Print view View original

11–20 of 79 posts

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#11

Post by jtheory »

Sir_Substance wrote: post #8
eliaspro wrote: post #2

Not surprised at all. And here we have the prime example, why the Docker-model of building and distributing containers is horrible when it comes to security and maintenance. Bundling dependencies for production environments has always been and always will be a terrible idea.

I see it as the opposite. If the maintainer of the container put some effort in, everyone could have a secure version of their software with minimal effort. The trick is to get people to care about their security. In theory, this is what open source is about. Why not assemble a taskforce to go and secure these containers?

The problem is that "secure version" is a constantly moving target; the taskforce would need to go around once a month (or whenever there's an urgent vulnerability discovered) and update apps that needed it.

If Docker apps were somehow integrated with maintained Linux repos, this could be possible by default -- e.g., all Docker images built on Debian stable dependencies would have their internal dependencies auto-upgraded with each Debian stable sub-release, and possibly be flagged as "needs human intervention" on major releases.

Have there been efforts to do anything like this? I'm new to the Docker world....

There needs to be, though, otherwise a "secure app" is always a temporary creation.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#12

Post by justincormack »

Docker Hub as a build service doesnt make it very easy to update older images; you can set manual triggers to rebuild current if the FROM container changes, but thats not automatic. Other dependencies are not very easy either as you only get one FROM, then everything else is probably from git repos, packages, language packaging tools or tarfiles, which obviously need checking for updates.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#13

Post by olavgg »

creshal wrote: post #9
jtheory wrote: post #7

Earlier quoted context omitted.

This sounds like an oversimplification, though: > Bundling dependencies for production environments has always been and always will be a terrible idea. We're considering Docker currently -- not for the distribution model at all, since we'd only ever use our own internally built & maintained images -- but as a clean way to break apart dependencies, and make it possible to run a diverse multiple-server-type environment…

> My own concerns revolve around how easy it will be to keep updated on RHEL patches, for example -- apparently we should be able to keep both host and app dependencies updated without much trouble, but it adds more complexity to the maintenance cycle (it seems). That's about the "problem" with Docker – it's deceptively easy to roll out everything as its own containerized app. Updating? Not so much. It turns Docker f…

Actually its pretty easy, I just did it yesterday for my PostgreSQL container.

Debian/Ubuntu example: sudo docker exec -it my_pgsql_container_name /bin/sh -c "apt-get update; apt-get -qqy upgrade; apt-get clean"

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#15

Post by dantiberian »

This isn't great, but it's not quite as terrible as its being made out to be for the official packages. The Mercurial bug is only relevant if you're using Mercurial with user supplied input on your production servers. Unlikely if you're not BitBucket. http://chargen.matasano.com/chargen/2015/3/17/this-new-vulne... Is a good read on the subject.

The libtasn1 bug seems to be only relevant if you're using GnuTLS. Again, not great but not the most widely used library either.

Cutting those two out cuts the number of vulnerable images in half and there's probably a few more rarely used programs with security issues further down the tail. Again, this isn't great, but it's not quite as terrible as the authors are making it to be.

The user supplied packages on the other hand seems to be quite a bit worse.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#19

Post by tomaac »

olavgg wrote: post #13
creshal wrote: post #9

Earlier quoted context omitted.

> My own concerns revolve around how easy it will be to keep updated on RHEL patches, for example -- apparently we should be able to keep both host and app dependencies updated without much trouble, but it adds more complexity to the maintenance cycle (it seems). That's about the "problem" with Docker – it's deceptively easy to roll out everything as its own containerized app. Updating? Not so much. It turns Docker f…

Actually its pretty easy, I just did it yesterday for my PostgreSQL container. Debian/Ubuntu example: sudo docker exec -it my_pgsql_container_name /bin/sh -c "apt-get update; apt-get -qqy upgrade; apt-get clean"

And what happens when you launch new container from the same image? You need to run apt-get/yum again. Or rebuild image.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#20

Post by jacques_chester »

jtheory wrote: post #7
eliaspro wrote: post #2

Not surprised at all. And here we have the prime example, why the Docker-model of building and distributing containers is horrible when it comes to security and maintenance. Bundling dependencies for production environments has always been and always will be a terrible idea.

This sounds like an oversimplification, though: > Bundling dependencies for production environments has always been and always will be a terrible idea. We're considering Docker currently -- not for the distribution model at all, since we'd only ever use our own internally built & maintained images -- but as a clean way to break apart dependencies, and make it possible to run a diverse multiple-server-type environment…

Basically, you're thinking of building a custom PaaS.

I'd just use an existing one. PaaSes require an enormous amount of work to make them featuresome and robust. That's all work you're spending that isn't user-facing value.

I've worked on Cloud Foundry and so obviously I think it's the bee's knees. You might prefer OpenShift.

If you're happy in the public cloud, you can host on Heroku, Pivotal Web Services (my employer's Cloud Foundry instance) or on Bluemix (IBM's Cloud Foundry instance).

Post reply on HN