4 ms·

Well, it's much, much easier for me to audit a CPAN module than a Docker image - the latter is practically impossible.

raesene9 8y ago
eh? Assuming automated builds, you can just read the dockerfile (and it's hierarchy if necessary), it's less complex syntax than perl by a long way. Even assuming no automated build, all the information is in the manifest, and using something like portainer it's pretty easy to read.
- palotasb 8y ago
  Don't a lot of OS images start by importing a non-transparent prebuilt tarball containing nontrivial binaries? I would hide the malware inside those.
  - ownagefool 8y ago
    Sure, but so could the OS or app distributors. You need to establish a baseline of trust somewhere, and this will likely be on the official (or your cherry picked official) images, and you build from there.
  - onion2k 8y ago
    They do, but you can easily see what's being used as a base image. If it's something odd then you should think twice about using it.
  - raesene9 8y ago
    The official images are made by the OS project themselves, so if you can get malware in there, you can just get your malware into debian/CentOS/alpine and not even bother with Docker hub :)
- heinrichhartman 8y ago
  > you can just read the dockerfile For many images, no Dockerfile is provided. And even if there is, it's not clear that it has been used to produce the software. I tried many times to reproduce images from Dockerfiles and failed: What `apt get update` does, depends on the current time and your network configuration. You can never be suer what you get from DockerHub. My strategy has been to copy the Dockerfiles and run `docker build` myself, instead of using the image files. Alas it's does not work very well.
  - raesene9 8y ago
    So it should generally be possible to go from image --> dockerfile as the information is included in the manifest. If you save an image as a .tar.gz you can extract the info from there or there are also tools to reverse engineer Dockerfiles from images https://samaritan.ai/blog/reversing-docker-images-into-dockerfiles/ https://samaritan.ai/blog/reversing-docker-images-into-docke... That is a good point about lack of reproducability though. I suppose an interesting attack would be to deliberately forge information in the manifest before pushing to Docker hub... I also tend to use anything other than the official images as "inspiration" and re-implement myself.
    - cyphar 8y ago
      > I suppose an interesting attack would be to deliberately forge information in the manifest before pushing to Docker hub... "Forge" is a bit of a strong word. The main reason Docker included build information in the image history was so that build caching would work (from memory). It's not meant to be an authoritative source of information about how an image was built at all (not to mention that "RUN apt-get update" tells you almost nothing about what packages were installed, when they were updated, etc). Personally I think that the current trend of using Dockerfiles is completely broken in terms of reproduciblity and introspectability (I'm working on a blog post to better explain the issue).
- csomar 8y ago
  How? The Dockerfile downloads a bunch of files/programs that it is not clear what they are? How are you going to automatically catch these?
Patrick_Devine 8y ago
You can use the `docker trust` to verify which key (if any) was used to sign a given docker image. The `docker history` command will also give you a list of each of the layers as well as the command which was used to create the layer.
- MPSimmons 8y ago
  It's trivial to insert software into the build pipeline without being noticed. Run your own devpi server, build a compromised version of any dependency you want, and you can install whatever you would like, with no sign of it in the Dockerfile.

eh? Assuming automated builds, you can just read the dockerfile (and it's hierarchy if necessary), it's less complex syntax than perl by a long way. Even assuming no automated build, all the information is in the manifest, and using something like portainer it's pretty easy to read.

palotasb 8y ago
Don't a lot of OS images start by importing a non-transparent prebuilt tarball containing nontrivial binaries? I would hide the malware inside those.
- ownagefool 8y ago
  Sure, but so could the OS or app distributors. You need to establish a baseline of trust somewhere, and this will likely be on the official (or your cherry picked official) images, and you build from there.
- onion2k 8y ago
  They do, but you can easily see what's being used as a base image. If it's something odd then you should think twice about using it.
- raesene9 8y ago
  The official images are made by the OS project themselves, so if you can get malware in there, you can just get your malware into debian/CentOS/alpine and not even bother with Docker hub :)
heinrichhartman 8y ago
> you can just read the dockerfile For many images, no Dockerfile is provided. And even if there is, it's not clear that it has been used to produce the software. I tried many times to reproduce images from Dockerfiles and failed: What `apt get update` does, depends on the current time and your network configuration. You can never be suer what you get from DockerHub. My strategy has been to copy the Dockerfiles and run `docker build` myself, instead of using the image files. Alas it's does not work very well.
- raesene9 8y ago
  So it should generally be possible to go from image --> dockerfile as the information is included in the manifest. If you save an image as a .tar.gz you can extract the info from there or there are also tools to reverse engineer Dockerfiles from images https://samaritan.ai/blog/reversing-docker-images-into-dockerfiles/ https://samaritan.ai/blog/reversing-docker-images-into-docke... That is a good point about lack of reproducability though. I suppose an interesting attack would be to deliberately forge information in the manifest before pushing to Docker hub... I also tend to use anything other than the official images as "inspiration" and re-implement myself.
  - cyphar 8y ago
    > I suppose an interesting attack would be to deliberately forge information in the manifest before pushing to Docker hub... "Forge" is a bit of a strong word. The main reason Docker included build information in the image history was so that build caching would work (from memory). It's not meant to be an authoritative source of information about how an image was built at all (not to mention that "RUN apt-get update" tells you almost nothing about what packages were installed, when they were updated, etc). Personally I think that the current trend of using Dockerfiles is completely broken in terms of reproduciblity and introspectability (I'm working on a blog post to better explain the issue).
csomar 8y ago
How? The Dockerfile downloads a bunch of files/programs that it is not clear what they are? How are you going to automatically catch these?

Patrick_Devine 8y ago

You can use the `docker trust` to verify which key (if any) was used to sign a given docker image. The `docker history` command will also give you a list of each of the layers as well as the command which was used to create the layer.

MPSimmons 8y ago
It's trivial to insert software into the build pipeline without being noticed. Run your own devpi server, build a compromised version of any dependency you want, and you can install whatever you would like, with no sign of it in the Dockerfile.