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

21–30 of 79 posts

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

#21

Post by KaiserPro »

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 that defeats the whole selling point of docker, which is no forward config, containers do not change once shipped.

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

#22

Post by KaiserPro »

justingood wrote: post #6
vacri wrote: post #3

"Containers have revolutionized software development by providing a very efficient path to take software written by developers and run it in production in a matter of minutes or hours, rather than days or months using traditional approaches." FUD. The technology of deployment does not change 'minutes or hours' into 'days or months' - it's management red tape that does that. In fact, in my use case, Docker takes a sim…

"The technology of deployment does not change 'minutes or hours' into 'days or months'" I wouldn't say that's true. We're transitioning into multiple languages, and want to have an environment that will allow future languages to be added as required. Building a generic infrastructure to run containers lets us run everything on the same base platform. Otherwise, we'd need to tailor the images and configuration for the…

Or, you could do what HPC has been doing for years and seperate the config from the machine.

What do I mean by that? shared drives.

Seriously, install python$ver plus dependenceies into /mnt/bin add it into your path. You now have a single source of (readonly optional) each binary version.

this means that you can have many versions of the same software all compiled in a different way. But because they are in the path, they can be transparently managed. Also it means that much of the config management is now in one place, making joining nodes super simple.

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

#23

Post by s_baby »

tomaac wrote: post #19
olavgg wrote: post #13

Earlier quoted context omitted.

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.

That's why you keep everything with state in a separate volume container. Attach volume to built image and that's it.

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

#24

Post by tomaac »

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…

Check out Project Atomic http://www.projectatomic.io/. Or its downstream project RHEL Atomic Host. The whole update process for the host is much simpler. Read more abou it here: http://rhelblog.redhat.com/2015/04/01/red-hat-enterprise-lin...

Note: I am not related to Redhat, but we are considering Docker, too. And we are evaluating how would Atomic fit in our infrastructure.

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

#25

Post by alextgordon »

s_baby wrote: post #23
tomaac wrote: post #19

Earlier quoted context omitted.

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

That's why you keep everything with state in a separate volume container. Attach volume to built image and that's it.

You can, if you want, mount your root as readonly so you're not tempted to modify it. Then it behaves like a Live CD.

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

#26

Post by vidarh »

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.

Do you believe that locally built "homegrown" deploys on average are going to be better or worse than these images?

Because I know what I'd bet on.

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

#27

Post by DyslexicAtheist »

DyslexicAtheist wrote: post #18

docker hub: the petri dish of choice for malware

dockers biggest strength is also its biggest weakness IMO. they did lots of changes to the default capabilities (linux capabilities) to improve security. But the underlying problem of fixing old bugs in images remains, along with that its contents are often a disorganized mess: Coming straight from the developer as a black box (more or less) into production environments (yeah when has that ever been a good idea?).

Docker IMO creates a "never touch a running system" attitude. The "running system" in this case is the docker image which nobody dares touching after the developer has left the company. (or the developer themselves have no idea anymore what it contained 3 weeks later)

Also the overhead of setting up containers in a secure way is even more work than not using docker in the first place (ever had too look seriously into SElinux? not something you do casually on the side as it's massively complex).

So the justification that "by using docker we save time on deployment" is a farce. I guess it creates new jobs though for container specialists.

to paraphrase Theo de Raadt:

‟You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can’t write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.”

EDIT: is it still possible in Docker/LXD to access /proc/sys/kernel/panic or /sys/class/thermal/cooling_device0/cur_state ? And how about consuming all the entropy of the host via /dev/random ?

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

#28

Post by ColinDabritz »

It might be interesting to have a gate on publishing images that explicitly runs tests for major known vulnerabilities. You could at minimum flag images as "known vulnerable", or reject publishing attempts.

The flag might make sense on a new vulnerability, and it could be applied automatically. Imagine [Tag: Heartbleed - Untested] when the vulnerability happened, then as the automated process rolls through the images [Tag: Heartbleed - vulnerable] [Tag: Heartbleed - no vulnerability detected]. Future images are required to pass first.

We have to be careful with widely distributed images.

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

#29

Post by jeromenerf »

s_baby wrote: post #23
tomaac wrote: post #19

Earlier quoted context omitted.

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

That's why you keep everything with state in a separate volume container. Attach volume to built image and that's it.

Mount data, logs, configuration, eventual extensions in the data container?

For pg, there might be some migration needed when jumping from a major version to the next. Which requires both versions installed, on Debian at least.

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

#30

Post by drzaiusapelord »

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 trick is to get people to care about their security.

Its 2015. If security isn't a priority by a project, then that project is just incompetent. That may be harsh sounding, but are we really talking about security as optional with internet facing services? This is what happens when devs build their own systems without the experience of being a sysadmin. There's a lot of kitchen sink and duct tape "does it work? Yes, then we're done," mentalities at play here. Not enough people are worrying about maintainability and upgradability.

Heck, most of these things ship with everything running as root. Its like we've regressed to the 90s with Docker and Docker-like technologies.

Post reply on HN