I don't see how that threat is new or now more pressing than ever. How would you even count something like `docker pull vesnpsexga/joomla` as typosquatting vs. `docker pull joomla`? It's not even close.
Users should limit there container runtime/podman/docker access to docker.io/library or use a pull-thru caching feature of their own registry to bring in stuff from hand-selected places in public registries like docker.io or quay.io to environments behind the firewall.
Or why aren’t more people interested in this?
Not sure, but maybe injecting into commonly used libraries via subdependencies is seen as a more effective method, getting more focus. Would be interesting to have a broader analysis of malicious artifacts!
then i go to work and i spend the majority of my week asking questions like "where is the dockerfile for this jimbob/diffusers image you're basing your work on?" or exhaust political capital on convincing leadership that it's worth our time to vendor all our dockerfiles from `scratch` up, and regularly rebuild them in ci vs just pulling them from dockerhub.
all the "if you use common sense you're fine" posts don't match my experiences in helping numerous companies un-fuck their container infrastructure
Unless you have access to unambiguously official images, like from Red Hat, most images are "random". There are tons of popular non-official images maintained by random organizations or people (e.g., bitnami, LinuxServer) that you just have to trust.
These kinds of repository are probably best used by drive-by malware.
I think this (and all) repository's download log should be made open, or at least made viewable prior to your downloading step as part of the trust profiling.
* chroot * cgroups * PrivateNetwork * PrivateTmp * isolated devices * IPAddressAllow * SocketBindAllow * ReadOnlyPaths
But no credible security researcher, security engineer or even Docker the company itself has ever considered Docker the container runtime to be a security mechanism (well, outside of the fact it's leveraging kernel namespaces)[0].
There's also a lot of really bad security hygiene when it comes to running docker images even if they could be secure: Docker runs programs by default as root and this gives programs quite a lot of possibility to escape a container, many containers are used in CI (DinD) which exposes the host docker daemon, most containers are not run with `--cap-drop all` which drops capabilities from the kernel[1], I have never seen a container run with `--security-opt=no-new-privileges` which would prevent escalating privileges using `setuid` or `setgid` binaries (leading to the same issue as running everything as root), etc, etc, etc;
[0]: https://docs.docker.com/engine/security/
[1]: https://man7.org/linux/man-pages/man7/capabilities.7.html
The big issues come in the fact that you may pass in proprietary/confidential files, for example Code, which is now at risk of being leaked and the company faces extortion. Or you have a network configuration where the malware can pivot onto another server and now your whole environment is exposed to risk.
