4 ms·

The amount of trust placed in DockerHub to serve the correct images to everyone for uncritical download and execution is insane to me. The whole industry does

by sneak 3y ago

The amount of trust placed in DockerHub to serve the correct images to everyone for uncritical download and execution is insane to me. The whole industry does it, and it's the same as "curl | bash" to specify image:tag and not image@hash. If I were TAO I'd apply for a job at Docker or their hosting provider.

Lemmi 3y ago
That's why you only pull official images and signed ones. And that's why I have an in-between step. Harbor.io allows you to configure it as a proxy with approval mechanism and cve scanning
- sneak 3y ago
  Docker content trust (ie signature checking) is disabled by default. We won't even do this for webpages, but we find it a fine default for code that executes inside critical infrastructure. It's utter madness. Cool to see someone is doing something about it.
api 3y ago
We have collectively decided as an industry to place infinite trust in a handful of vendors for the sake of convenience. Auth providers (OIDC), cloud providers, and numerous software repositories and SaaS providers effectively have root on the entire universe. A major compromise of any number of these large vendors could expose millions of systems to total compromise.
- deleted 3y ago
  [deleted]
- sneak 3y ago
  Resultantly, these systems are almost certainly already compromised by organizations skilled enough to not get caught.
  - api 3y ago
    I'd say nation states, which means the US and possibly other nation states effectively have root on virtually all SaaS systems. It's exactly the architecture I'd promote if I wanted a total panopticon, but I'm not suggesting a conspiracy. Ease of use is the most powerful force in computing and history has shown that people will trade privacy, security, freedom, cost, and virtually anything else for it. It does make a certain amount of sense. Time is non-fungible; no amount of money can buy more of it. So ease of use by saving time is extremely valuable and commands a high price. The problem is that IMO the cost of all this SaaS automation is higher than most people understand. There's some rather huge hidden costs here.
anonfunction 3y ago
What's TAO?
- Infernal 3y ago
  I am not sure but maybe referring to this? https://en.wikipedia.org/wiki/Tailored_Access_Operations https://en.wikipedia.org/wiki/Tailored_Access_Operations
- zalanak 3y ago
  Might be referring to “Tailored Access Operations” which was an NSA office
samcat116 3y ago
You could say this about any service serving software artifacts?
- sneak 3y ago
  Unsigned ones, yes.
  - pkage 3y ago
    That just moves the trust requirement up the chain, and assumes that the image wasn’t compromised pre-signing (either intentionally or unintentionally)
    - jabradoodle 3y ago
      It doesn't, it removes/reduces one step, and leaves another one that is there regardless.
nineplay 3y ago
What's the alternative? I don't know of any reason to think that tarballs or <os> installers are any better. I suppose I could clone the code and look for security flaws myself but I'm no expert and on something like nginx it's certain to be a waste of my time.
- eatmyshorts 3y ago
  OCI registries. Harbor + Notary + admission controllers - AKA private image repository with image signing. Sigstore. Another method for signing & verifying artifacts.
radlad 3y ago
> it's the same as "curl | bash" While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than running arbitrary code inside of a container. Even if you specify a hash, are you actually checking all of the code and binaries in that image? What about the image base (e.g. Alpine, Debian) and their packages?
- pphysch 3y ago
  There have been a lot of container escape exploits
  - radlad 3y ago
    Sure... but it's still not "the same as" running on your host.
    - TeMPOraL 3y ago
      That depends on how you're running it. You wouldn't want a compromised image to be the base for your build containers, which get access to your product's source code via volume mount, or to secret keys via environment variables.
- peterbecich 3y ago
  I'm a big fan of Nix Flakes but they appear to have the same issue here as "curl | bash". I mention this because Flakes can do much of what Docker can do, but do not use containers or virtualization. The official NixPkgs are carefully vetted. Nix Flakes make it more convenient to pull in sources from outside NixPkgs. As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. There are more benefits to Nix Flakes than native execution so containerizing them somehow might be an acceptable compromise.
  - one-punch 3y ago
    > As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. You may be interested in nix snapshotter, which can run nix packages in containerd. https://news.ycombinator.com/item?id=37407758 https://news.ycombinator.com/item?id=37407758
Proven 3y ago
[dead]

by sneak 3y ago

Lemmi 3y ago

That's why you only pull official images and signed ones. And that's why I have an in-between step. Harbor.io allows you to configure it as a proxy with approval mechanism and cve scanning

sneak 3y ago
Docker content trust (ie signature checking) is disabled by default. We won't even do this for webpages, but we find it a fine default for code that executes inside critical infrastructure. It's utter madness. Cool to see someone is doing something about it.

api 3y ago

We have collectively decided as an industry to place infinite trust in a handful of vendors for the sake of convenience. Auth providers (OIDC), cloud providers, and numerous software repositories and SaaS providers effectively have root on the entire universe. A major compromise of any number of these large vendors could expose millions of systems to total compromise.

deleted 3y ago
[deleted]
sneak 3y ago
Resultantly, these systems are almost certainly already compromised by organizations skilled enough to not get caught.
- api 3y ago
  I'd say nation states, which means the US and possibly other nation states effectively have root on virtually all SaaS systems. It's exactly the architecture I'd promote if I wanted a total panopticon, but I'm not suggesting a conspiracy. Ease of use is the most powerful force in computing and history has shown that people will trade privacy, security, freedom, cost, and virtually anything else for it. It does make a certain amount of sense. Time is non-fungible; no amount of money can buy more of it. So ease of use by saving time is extremely valuable and commands a high price. The problem is that IMO the cost of all this SaaS automation is higher than most people understand. There's some rather huge hidden costs here.

anonfunction 3y ago

What's TAO?

Infernal 3y ago
I am not sure but maybe referring to this? https://en.wikipedia.org/wiki/Tailored_Access_Operations https://en.wikipedia.org/wiki/Tailored_Access_Operations
zalanak 3y ago
Might be referring to “Tailored Access Operations” which was an NSA office

samcat116 3y ago

You could say this about any service serving software artifacts?

sneak 3y ago
Unsigned ones, yes.
- pkage 3y ago
  That just moves the trust requirement up the chain, and assumes that the image wasn’t compromised pre-signing (either intentionally or unintentionally)
  - jabradoodle 3y ago
    It doesn't, it removes/reduces one step, and leaves another one that is there regardless.

nineplay 3y ago

What's the alternative? I don't know of any reason to think that tarballs or <os> installers are any better. I suppose I could clone the code and look for security flaws myself but I'm no expert and on something like nginx it's certain to be a waste of my time.

eatmyshorts 3y ago
OCI registries. Harbor + Notary + admission controllers - AKA private image repository with image signing. Sigstore. Another method for signing & verifying artifacts.

radlad 3y ago

> it's the same as "curl | bash" While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than running arbitrary code inside of a container. Even if you specify a hash, are you actually checking all of the code and binaries in that image? What about the image base (e.g. Alpine, Debian) and their packages?

pphysch 3y ago
There have been a lot of container escape exploits
- radlad 3y ago
  Sure... but it's still not "the same as" running on your host.
  - TeMPOraL 3y ago
    That depends on how you're running it. You wouldn't want a compromised image to be the base for your build containers, which get access to your product's source code via volume mount, or to secret keys via environment variables.
peterbecich 3y ago
I'm a big fan of Nix Flakes but they appear to have the same issue here as "curl | bash". I mention this because Flakes can do much of what Docker can do, but do not use containers or virtualization. The official NixPkgs are carefully vetted. Nix Flakes make it more convenient to pull in sources from outside NixPkgs. As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. There are more benefits to Nix Flakes than native execution so containerizing them somehow might be an acceptable compromise.
- one-punch 3y ago
  > As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. You may be interested in nix snapshotter, which can run nix packages in containerd. https://news.ycombinator.com/item?id=37407758 https://news.ycombinator.com/item?id=37407758

Proven 3y ago

[dead]