8 ms·

If you didn't build the container, then you are putting all your trust and your companies private bits in the hands of Joe Random. Please do not blame the tech

If you didn't build the container, then you are putting all your trust and your companies private bits in the hands of Joe Random. Please do not blame the technology. This problem existed long before containers and will exist long after they are gone. This is people trusting unknown anonymous third parties to build things that will run in their datacenter.

paulddraper 8y ago
The blame with npm, DockerHub, etc. basically boils down to "it makes it too easy to share and run software".
- MisterTea 8y ago
  There used to be this thing called software engineering. You are presented a problem and you or a team come up with possible solutions choosing carefully the right tools and components for the job. Now we are entering the everything as a service era which includes software engineering. Instead of designing a solution you download someone else's, duct tape on a few packages, tweak variables and publish it. You can also blame the breakneck pace demanded by today's tech sector where everything needed to be deployed yesterday in order to beat the other guy to the silicon valley millionaire finish line. You can say it's a mix of impatience and laziness.
  - paulddraper 8y ago
    > There used to be this thing called software engineering. And computers were once accommodated with the same with the space they deserved in large rooms. Now we are entering the everything as miniature. Want more RAM? Throw out the whole thing, because it can't be fiddled. You could say it's a mixture of impatience and abject cheapness.
    - nine_k 8y ago
      Hardware may be cheap or expensive, it does not make a lot of difference. The key is whether you see your data, or your customers' data, as a precious thing that needs care and protection. If you do, you make the best effort to select the right software, understand how it works, deploy it correctly and securely, etc. If you don't, you just slap together something that sort of works from the easiest-to-obtain parts, and concentrate on other things. A lot of people don't care too much about their own personal data; some of them are developers, product managers, even CEOs.
    - TeMPOraL 8y ago
      > Now we are entering the everything as miniature. Want more RAM? Throw out the whole thing, because it can't be fiddled. Development of some technologies seems to happen on some weird curve like this: end-user control / flexibility / repairability ^ | ........ | .. .. | .. .. | ... ... | .... ....... | ..... .... +--------------------------------------------> power / money-making capability (Not really sure about the Y axis label; I'm having trouble expressing the quality I'm thinking of.) Things start as prototypes - hard to sell, hard to use, hard to tweak on user end. Over time, they become more flexible - think of e.g. PCs with interchangeable components. This is the golden era for end-users. They can fix stuff themselves, they can replace or upgrade components. The technology reaches maturity, and the only way from there is downhill - as businesses find new ways to fuck users over, both purposefully and incidentally. Make things smaller. More integrated. Sealed. Protected. The end result is the ultimate money-maker - a black box you lease and can only use as long as you're paying for the subscription.
  - Brotkrumen 8y ago
    This effect isn't new, even in ye olde days of waterfall. Back then it was called rapid prototyping and first system syndrome. The rapid just got rapider today with easy packages, frameworks and containers. The prototypes just became "web scale" and are run way beyond their intended lifespan, just like any first system is.
  - weberc2 8y ago
    I'm not sure what distinction you're trying to make? Build it yourself vs reuse? Old-fashioned file-sharing reuse vs modern network-based package management? Sounds like you're mocking anything that isn't homegrown or acquired via floppy disk, but I want to give you the benefit of the doubt...
- LinuxBender 8y ago
  I would suggest that depends on how they present the community artifacts. If they provide a good deal of obvious disclaimers that the artifacts are built by Joe Random and "Use at your own peril", etc, then they are probably covered. If not, then they are guilty of conditioning people with bad behavior. For an example of how this existed long before Linux containers: There are third party RPM and APT package repositories that have existed for a very long time. The packages are not vetted by a company and there is no legal culpability for anything nefarious being contained within. People use these packages at their own peril and it is assumed they have mitigating controls to reduce risk. Github is community contributed code and there is no enforceable legal contract between the developer and the consumer. The same thing applies. Use at your own peril and have mitigating controls (code diff reviews, static analysis, legal review, etc) This is especially true for all those projects under the MIT license.
notheguyouthink 8y ago
Isn't that always true though? This is just one additional layer of trust. Sure, there are reasonable layers we should care about, but you're rarely, if ever, going to be doing everything and trust everything. Ie: > If you didn't build the container.. > If you didn't build the package on Debian.. > If you didn't verify the source code when compiling by hand.. etc.
- LinuxBender 8y ago
  I think it is about legal culpability. If I am running CentOS in my datacenter, there is some degree of confidence that the packages were rebuilt by the CentOS team, a few members of which are Redhat employees. Redhat have an obligation to make reasonable effort to keep malicious code out of their supported software. If there is a commercially supported version of Debian, then the same would apply. If I pull in RPM's, Containers, VM Images built by Joe Random, I am legally on my own. My customers will be furious when they find out I have done this and the court will say that I did not make reasonable effort to protect my customers.
  - raesene9 8y ago
    For commercial software, there may be some level of legal liability, but it would depend entirely on your contract, and I'd imagine if you look at most standard contracts, they disclaim all such liability. For CentOS (or any other open source software) you may have that confidence but you have no contract :) Now do Redhat/Debian package maintainers do detailed security reviews on all the software they distribute... I don't know but the odds would say it's not likely as they don't employ (to the best of my knowledge) the number of code review professionals that would be required to do that. And of course as soon as you venture off in to other repo's (npm, rubygems, CPAN, nuget etc) you're entirely on your own.
    - LinuxBender 8y ago
      I agree, I am riding on the backs of people using RHEL. There is a direct contractual relationship between those companies and Redhat. In my case, I am relying on the other companies having that relationship and I can still say some effort is being made to validate the supported packages. While I can not sue anyone, I can say that I am using an OS that has some degree of code validation and feature set stability. For sure, things like npn, gems, cpan, pear, pip, etc... is basically back to square one with Joe Random. Each of those things can be pulled into a code repo, built internally and turned into RPM packages. I agree that the effort to code diff review these things is quite large. It is likely still a smaller effort than rewriting all of this code from scratch.
theptip 8y ago
It's true that this problem is not unique to container tech -- it's a problem that every packaging ecosystem faces. Who polices what packages are available? And how many eyes are on these packages, to make sure that they are safe? It would be pretty difficult to sneak a covert Monero miner into an officially approved mainline Debian package. However there is a sense in which this is a problem with container tech, in that there is no container equivalent of `deb http://deb.debian.org/debian http://deb.debian.org/debian stretch main` (yet!). This is a statement about the maturity of the ecosystem, rather than a criticism of the technology itself, as you say. But I think that it's meaningful to say that this is a problem that containers currently have, that Debian (or other Linux distro) packages don't face to the same extent.
- zenlikethat 8y ago
  > However there is a sense in which this is a problem with container tech, in that there is no container equivalent of `deb http://deb.debian.org/debian http://deb.debian.org/debian stretch main` (yet!). That's what the Docker standard library is
  - theptip 8y ago
    Close, but not quite https://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/ https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln...
colonelpopcorn 8y ago
docker run some/container is basically equivalent to curling a shell script and piping it straight to bash isn't it?
- raesene9 8y ago
  not really, Docker (and similar containerization technologies) provide a restricted environment for the downloaded code to execute in (by default, it is possible for users to remove the restrictions) Assuming a default Docker engine install, and no options passed as part of the run, an attacker could DoS the box most likely, and may be able to intercept traffic on the Docker bridge network (although that's not a trivial thing to pull off), but they're unlikely (absent an exploitable Linux kernel flaw) to be able to easily compromise the underlying host.
TheGodfather 8y ago
Couldn't have said it better myself.
jacques_chester 8y ago
> This is people trusting unknown anonymous third parties to build things that will run in their datacenter. Red Hat, Canonical, Pivotal (I work for Pivotal) all provide this kind of assurance and it's a lot of our bread and butter income to do so. In particular, Cloud Foundry uses buildpacks, providing runtime binaries with a chain of custody from sourcecode to the buildpack uploaded to the installation. Buildpacks make this overall problem a lot easier, actually. You don't need to track the underlying base OS image or manage the runtime binaries. The platform does it for you. But you will still be responsible for tracking more immediate dependencies (NPM, Maven etc), which is a poorly-solved problem currently.
zilchers 8y ago
Exactly, similar issue exists with nearly all package manager tools - you’re putting a lot of trust in a lot of people you don’t know.

paulddraper 8y ago

The blame with npm, DockerHub, etc. basically boils down to "it makes it too easy to share and run software".

MisterTea 8y ago
There used to be this thing called software engineering. You are presented a problem and you or a team come up with possible solutions choosing carefully the right tools and components for the job. Now we are entering the everything as a service era which includes software engineering. Instead of designing a solution you download someone else's, duct tape on a few packages, tweak variables and publish it. You can also blame the breakneck pace demanded by today's tech sector where everything needed to be deployed yesterday in order to beat the other guy to the silicon valley millionaire finish line. You can say it's a mix of impatience and laziness.
- paulddraper 8y ago
  > There used to be this thing called software engineering. And computers were once accommodated with the same with the space they deserved in large rooms. Now we are entering the everything as miniature. Want more RAM? Throw out the whole thing, because it can't be fiddled. You could say it's a mixture of impatience and abject cheapness.
  - nine_k 8y ago
    Hardware may be cheap or expensive, it does not make a lot of difference. The key is whether you see your data, or your customers' data, as a precious thing that needs care and protection. If you do, you make the best effort to select the right software, understand how it works, deploy it correctly and securely, etc. If you don't, you just slap together something that sort of works from the easiest-to-obtain parts, and concentrate on other things. A lot of people don't care too much about their own personal data; some of them are developers, product managers, even CEOs.
  - TeMPOraL 8y ago
    > Now we are entering the everything as miniature. Want more RAM? Throw out the whole thing, because it can't be fiddled. Development of some technologies seems to happen on some weird curve like this: end-user control / flexibility / repairability ^ | ........ | .. .. | .. .. | ... ... | .... ....... | ..... .... +--------------------------------------------> power / money-making capability (Not really sure about the Y axis label; I'm having trouble expressing the quality I'm thinking of.) Things start as prototypes - hard to sell, hard to use, hard to tweak on user end. Over time, they become more flexible - think of e.g. PCs with interchangeable components. This is the golden era for end-users. They can fix stuff themselves, they can replace or upgrade components. The technology reaches maturity, and the only way from there is downhill - as businesses find new ways to fuck users over, both purposefully and incidentally. Make things smaller. More integrated. Sealed. Protected. The end result is the ultimate money-maker - a black box you lease and can only use as long as you're paying for the subscription.
- Brotkrumen 8y ago
  This effect isn't new, even in ye olde days of waterfall. Back then it was called rapid prototyping and first system syndrome. The rapid just got rapider today with easy packages, frameworks and containers. The prototypes just became "web scale" and are run way beyond their intended lifespan, just like any first system is.
- weberc2 8y ago
  I'm not sure what distinction you're trying to make? Build it yourself vs reuse? Old-fashioned file-sharing reuse vs modern network-based package management? Sounds like you're mocking anything that isn't homegrown or acquired via floppy disk, but I want to give you the benefit of the doubt...
LinuxBender 8y ago
I would suggest that depends on how they present the community artifacts. If they provide a good deal of obvious disclaimers that the artifacts are built by Joe Random and "Use at your own peril", etc, then they are probably covered. If not, then they are guilty of conditioning people with bad behavior. For an example of how this existed long before Linux containers: There are third party RPM and APT package repositories that have existed for a very long time. The packages are not vetted by a company and there is no legal culpability for anything nefarious being contained within. People use these packages at their own peril and it is assumed they have mitigating controls to reduce risk. Github is community contributed code and there is no enforceable legal contract between the developer and the consumer. The same thing applies. Use at your own peril and have mitigating controls (code diff reviews, static analysis, legal review, etc) This is especially true for all those projects under the MIT license.

notheguyouthink 8y ago

Isn't that always true though? This is just one additional layer of trust. Sure, there are reasonable layers we should care about, but you're rarely, if ever, going to be doing everything and trust everything. Ie: > If you didn't build the container.. > If you didn't build the package on Debian.. > If you didn't verify the source code when compiling by hand.. etc.

LinuxBender 8y ago
I think it is about legal culpability. If I am running CentOS in my datacenter, there is some degree of confidence that the packages were rebuilt by the CentOS team, a few members of which are Redhat employees. Redhat have an obligation to make reasonable effort to keep malicious code out of their supported software. If there is a commercially supported version of Debian, then the same would apply. If I pull in RPM's, Containers, VM Images built by Joe Random, I am legally on my own. My customers will be furious when they find out I have done this and the court will say that I did not make reasonable effort to protect my customers.
- raesene9 8y ago
  For commercial software, there may be some level of legal liability, but it would depend entirely on your contract, and I'd imagine if you look at most standard contracts, they disclaim all such liability. For CentOS (or any other open source software) you may have that confidence but you have no contract :) Now do Redhat/Debian package maintainers do detailed security reviews on all the software they distribute... I don't know but the odds would say it's not likely as they don't employ (to the best of my knowledge) the number of code review professionals that would be required to do that. And of course as soon as you venture off in to other repo's (npm, rubygems, CPAN, nuget etc) you're entirely on your own.
  - LinuxBender 8y ago
    I agree, I am riding on the backs of people using RHEL. There is a direct contractual relationship between those companies and Redhat. In my case, I am relying on the other companies having that relationship and I can still say some effort is being made to validate the supported packages. While I can not sue anyone, I can say that I am using an OS that has some degree of code validation and feature set stability. For sure, things like npn, gems, cpan, pear, pip, etc... is basically back to square one with Joe Random. Each of those things can be pulled into a code repo, built internally and turned into RPM packages. I agree that the effort to code diff review these things is quite large. It is likely still a smaller effort than rewriting all of this code from scratch.

theptip 8y ago

It's true that this problem is not unique to container tech -- it's a problem that every packaging ecosystem faces. Who polices what packages are available? And how many eyes are on these packages, to make sure that they are safe? It would be pretty difficult to sneak a covert Monero miner into an officially approved mainline Debian package. However there is a sense in which this is a problem with container tech, in that there is no container equivalent of `deb http://deb.debian.org/debian http://deb.debian.org/debian stretch main` (yet!). This is a statement about the maturity of the ecosystem, rather than a criticism of the technology itself, as you say. But I think that it's meaningful to say that this is a problem that containers currently have, that Debian (or other Linux distro) packages don't face to the same extent.

zenlikethat 8y ago
> However there is a sense in which this is a problem with container tech, in that there is no container equivalent of `deb http://deb.debian.org/debian http://deb.debian.org/debian stretch main` (yet!). That's what the Docker standard library is
- theptip 8y ago
  Close, but not quite https://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/ https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln...

colonelpopcorn 8y ago

docker run some/container is basically equivalent to curling a shell script and piping it straight to bash isn't it?

raesene9 8y ago
not really, Docker (and similar containerization technologies) provide a restricted environment for the downloaded code to execute in (by default, it is possible for users to remove the restrictions) Assuming a default Docker engine install, and no options passed as part of the run, an attacker could DoS the box most likely, and may be able to intercept traffic on the Docker bridge network (although that's not a trivial thing to pull off), but they're unlikely (absent an exploitable Linux kernel flaw) to be able to easily compromise the underlying host.

TheGodfather 8y ago

Couldn't have said it better myself.

jacques_chester 8y ago

> This is people trusting unknown anonymous third parties to build things that will run in their datacenter. Red Hat, Canonical, Pivotal (I work for Pivotal) all provide this kind of assurance and it's a lot of our bread and butter income to do so. In particular, Cloud Foundry uses buildpacks, providing runtime binaries with a chain of custody from sourcecode to the buildpack uploaded to the installation. Buildpacks make this overall problem a lot easier, actually. You don't need to track the underlying base OS image or manage the runtime binaries. The platform does it for you. But you will still be responsible for tracking more immediate dependencies (NPM, Maven etc), which is a poorly-solved problem currently.

zilchers 8y ago

Exactly, similar issue exists with nearly all package manager tools - you’re putting a lot of trust in a lot of people you don’t know.