Hello,

 

I think this is a fantastic resource for adding functionality to unraid.  But, as I am essentially running software repackaged by third parties, how can I be sure the docker containers here do what they advertise, and nothing else?

 

Thanks

You really can't. The best you could do is look at the Docker Container's Project page, find the Dockerfile and supporting files used for startup scripts and then do the 'docker build' yourself.

 

Even with plugins you have the same issues and concerns.

Exactly what BRiT stated.  Best that I can say is that if there ever was a report of malware present in a container, immediate steps would be taken to "blacklist" the container

Even with plugins you have the same issues and concerns.

Actually, even worse since a plugin has complete access to your entire system.  Containers on the other hand only have access to what you explicitly give them access to  (ie: I can't forsee why Plex would require access to your saved banking statements, so why give it access?)

https://github.com/docker/notary

 

That will go some way to helping when it's released. You can always verify containers do what they advertise by viewing their Dockerfile's on github etc. It requires knowing a little about Linux to understand the innards though.

 

You can look at the containers on Docker hub too and review the comments to see if anybody has raised such an issue.

 

With a fully open-sourced solution like Docker it's highly unlikely anyone would try anything nefarious and not get caught. Docker is just a packaging mechanism and whilst it's possible to include unsolicited packages within this structure, a self-policing community such as this will go a long way towards solving your concerns.

https://github.com/docker/notary

 

That will go some way to helping when it's released. You can always verify containers do what they advertise by viewing their Dockerfile's on github etc. It requires knowing a little about Linux to understand the innards though.

 

You can look at the containers on Docker hub too and review the comments to see if anybody has raised such an issue.

 

With a fully open-sourced solution like Docker it's highly unlikely anyone would try anything nefarious and not get caught. Docker is just a packaging mechanism and whilst it's possible to include unsolicited packages within this structure, a self-policing community such as this will go a long way towards solving your concerns.

 

Even examining the docker container's Dockerfile and the scripts used in starting isn't enough. What becomes extremely dangerous is when the Docker Container does automatic updates. One could compromise all the auto-updating containers by compromising where they pull their auto-updates from.

 

Given the recent hack on Plex, imagine if they got a little further where they slipped in some nefarious code into the Plex repository. Now your auto-updating Plex* Docker Containers will pull down that evil update.

https://github.com/docker/notary

 

That will go some way to helping when it's released. You can always verify containers do what they advertise by viewing their Dockerfile's on github etc. It requires knowing a little about Linux to understand the innards though.

 

You can look at the containers on Docker hub too and review the comments to see if anybody has raised such an issue.

 

With a fully open-sourced solution like Docker it's highly unlikely anyone would try anything nefarious and not get caught. Docker is just a packaging mechanism and whilst it's possible to include unsolicited packages within this structure, a self-policing community such as this will go a long way towards solving your concerns.

 

Even examining the docker container's Dockerfile and the scripts used in starting isn't enough. What becomes extremely dangerous is when the Docker Container does automatic updates. One could compromise all the auto-updating containers by compromising where they pull their auto-updates from.

 

Given the recent hack on Plex, imagine if they got a little further where they slipped in some nefarious code into the Plex repository. Now your auto-updating Plex* Docker Containers will pull down that evil update.

Which is why auto updating violates best practices for Docker Containers. 

https://github.com/docker/notary

 

That will go some way to helping when it's released. You can always verify containers do what they advertise by viewing their Dockerfile's on github etc. It requires knowing a little about Linux to understand the innards though.

 

You can look at the containers on Docker hub too and review the comments to see if anybody has raised such an issue.

 

With a fully open-sourced solution like Docker it's highly unlikely anyone would try anything nefarious and not get caught. Docker is just a packaging mechanism and whilst it's possible to include unsolicited packages within this structure, a self-policing community such as this will go a long way towards solving your concerns.

 

Even examining the docker container's Dockerfile and the scripts used in starting isn't enough. What becomes extremely dangerous is when the Docker Container does automatic updates. One could compromise all the auto-updating containers by compromising where they pull their auto-updates from.

 

Given the recent hack on Plex, imagine if they got a little further where they slipped in some nefarious code into the Plex repository. Now your auto-updating Plex* Docker Containers will pull down that evil update.

Which is why auto updating violates best practices for Docker Containers.

 

 

Sir, i must respectfully disagree. Saying that Containers should not have autoupdates, is like saying an operating system should not have autoupdates. No There is absoultly no garantee that nobody  could insert malisous code into your software, but the problem then is with code\repo maintainer. e.g. My containers autoupdate from a) git or b) ubuntu repo. And lets all be honest getting malous code on the autors git should be so hard that if you sucessed anyone would warrent  to stop using said software alltogther. And getting the code onto ubuntu repo is not that easy either.

 

Imho, Its not about wether or not to autoupdate, its all about what sources one use for such activites. it is all in the chain of trust. just like certificates(SSL).

User trust Docker Author whom in turn trusts "ubuntu security team"  or software author (via git or souch). The again trust someone else to do something.

 

Lets look at any non autoupdateing container, and what happens when a new version of included software is released.

 

1. Docker Maintainer gets notified of an updated software.

2. Docker maintainer updates his\hers code to reflect **RUN apt-get install -y software-package-1.8.<newversion>.deb**

3. Docker maintainer push this new code to docker registry and causes delays\workload to the registry

4. User gets notified that update is needed.

5. User installs the new update.

6.

7. Profit

 

At what point do you see any malware controll of the new software package  ? It wont happen, because its a lot of work, and there is not many docker container maintainers capable of even detecting  said malware.

 

Also to the point. I Could not find any mention of not autoupdateing via docker. Infact i attended a seminar where the topic was automatic updateing and maintance of containers.

Which is why auto updating violates best practices for Docker Containers.

 

It does?

 

How is auto-updating on startup using `apt-get update -y` any different from what `docker build` would do as part of a Dockerfile? If malicious people are able to get their malware into the upstream repo's we're all f**ked anyway. Not going to happen.

 

Even examining the docker container's Dockerfile and the scripts used in starting isn't enough. What becomes extremely dangerous is when the Docker Container does automatic updates. One could compromise all the auto-updating containers by compromising where they pull their auto-updates from.

 

Given the recent hack on Plex, imagine if they got a little further where they slipped in some nefarious code into the Plex repository. Now your auto-updating Plex* Docker Containers will pull down that evil update.

 

At the risk of being incendiary, comparing a forum hack which are (sadly) now common place to a repository hack is not a fair comparison at all.

 

The only scenario in which I agree with your comprising of where they pull the auto-update from is if the code is hosted on some random web-server that isn't git or something. Most updates are likely to be `apt-get update -y` or similar as I've already stated if this mechanism gets compromised then a lot bigger problems than Docker containers exist. Imagine all the servers around the world that would go down. Sheesh.

 

Long story short, I don't believe auto-updating poses any greater risk. In fact, arguably it increases the lifespan of the container meaning that end users are not reliant upon the maintainer to update software if problems are found. There are dozens of containers on Docker hub which have old, outdated software and it's a huge problem that Docker is trying to address. Noone has found the silver bullet yet, if you have then we're all ears.

It does?

 

How is auto-updating on startup using `apt-get update -y` any different from what `docker build` would do as part of a Dockerfile? If malicious people are able to get their malware into the upstream repo's we're all f**ked anyway. Not going to happen.

 

I've sat both sides of the fence on updating in containers, my preference is if that if you're going to do it, it should be optional for the user (edge=1, type deal).

 

I don't like apt updates in the container though, i prefer to do any updates like that at the image level, although i did suggest it as a fix for a container that was installing git in an edge routine and was failing because of dependency changes in apt.

 

The docker best practices that squid was referring to are not official docker ones per se , but guidelines for dockers in the unraid environment.

 

I don't think malware is the issue as such though, more stability,  with containers self updating, things can break and support becomes a headache with a bajillion different versions out there.

Updating at the image level does of course put the onus squarely on the docker author, and if they should go walkabout then things can get fackered.

 

which is why i've advocated for a long time now for either a shared github for docker authors or shared rights on individual git repo's, so if someone does go on a wander, another author can take up the reins.

Updating at the image level does of course put the onus squarely on the docker author, and if they should go walkabout then things can get fackered.

 

which is why i've advocated for a long time now for either a shared github for docker authors or shared rights on individual git repo's, so if someone does go on a wander, another author can take up the reins.

 

Create an unraid organisation on github and BOOM.

It does?

 

How is auto-updating on startup using `apt-get update -y` any different from what `docker build` would do as part of a Dockerfile? If malicious people are able to get their malware into the upstream repo's we're all f**ked anyway. Not going to happen.

 

I've sat both sides of the fence on updating in containers, my preference is if that if you're going to do it, it should be optional for the user (edge=1, type deal).

 

I don't like apt updates in the container though, i prefer to do any updates like that at the image level, although i did suggest it as a fix for a container that was installing git in an edge routine and was failing because of dependency changes in apt.

 

The docker best practices that squid was referring to are not official docker ones per se , but guidelines for dockers in the unraid environment.

 

I don't think malware is the issue as such though, more stability,  with containers self updating, things can break and support becomes a headache with a bajillion different versions out there.

 

* edge=1 suggest to me that one opt-inn to use beta\unstable software not that one wants to use "latest offical", but then again English is my third language.

* If dockers in a unraid enviroment wants that as a best practise, we (linuxserver.io) shall take a offical stance agains. The goal is to keep target software at "latest\greatest" everything else is secondary.

* As for Stability, the most common reason any software is updated is too improve stability. But then again, yes you are\could be right, sometimes updates will cause software to break\systems to become unstable. However highly unlikly

 

Updating at the image level does of course put the onus squarely on the docker author, and if they should go walkabout then things can get fackered.

 

which is why i've advocated for a long time now for either a shared github for docker authors or shared rights on individual git repo's, so if someone does go on a wander, another author can take up the reins.

 

This is why we need more containers like "Linuxserver.io" where we'd  love more authors and contribs (To excalty that ensure that we always have support\maintainers)

A major premise of docker is that anyone at any time can pull down the exact same version of the container and get exactly the same experience. Autoupdating of a container goes completely against this. Now there is no way to guarantee the users have exactly the same experience. There is nothing to debate about this.

A major premise of docker is that anyone at any time can pull down the exact same version of the container and get exactly the same experience. Autoupdating of a container goes completely against this. Now there is no way to guarantee the users have exactly the same experience. There is nothing to debate about this.

And that is what I meant by best practice

end of the day though diversity is good and if a docker author's approach on the subject isn't to your liking, with the choice on offer you can nine times out of time find an alternative.

end of the day though diversity is good and if a docker author's approach on the subject isn't to your liking, with the choice on offer you can nine times out of time find an alternative.

 

Absolutely.

 

I was merely pointing out how sometimes usability and security are diametric opposites.

 

Also, want to point out, if it wasn't already been brought up, that Authenticity is not the same as Security. Just because you know this application/container is claimed to be published by XYZ does not mean it is secure and won't do something nasty. Authenticity keys get stolen all the time, just look at all the SSL Certificate / Digital Certificate Authority hacks over the last five years.

 

A major premise of docker is that anyone at any time can pull down the exact same version of the container and get exactly the same experience. Auto-updating of a container goes completely against this. Now there is no way to guarantee the users have exactly the same experience. There is nothing to debate about this.

 

I Agree this is a major premise and for software that spans 1000's of system in a cluster like configuration i could not agree more at all. It makes scaling\moving and such so much more safe\convenient etc. The major flaw is off-course to scale updating containers. e.g. pushing a updated image with a newer\different version of node.js to 10's of hosts and 100's of containers make it a different environment while the container cycle is rebooting. This is something we are struggling with at our data center, and i know many others is trying to figure out as well. (no the auto-update is not the answer there). But luckily we (or at least I) do not require a "identical" user experience. But yes you are right.

 

 

end of the day though diversity is good and if a docker author's approach on the subject isn't to your liking, with the choice on offer you can nine times out of time find an alternative.

 

 

 

I was merely pointing out how sometimes usability and security are diametric opposites.

 

Also, want to point out, if it wasn't already been brought up, that Authenticity is not the same as Security. Just because you know this application/container is claimed to be published by XYZ does not mean it is secure and won't do something nasty. Authenticity keys get stolen all the time, just look at all the SSL Certificate / Digital Certificate Authority hacks over the last five years.

 

 

 

Totally right.