[coldtea]

>Auditing a docker container is way more difficult/complex.

As long as it doesn't have access to outside of the container, who cares?

You check the dockerfile, see what access it allows, and build the container.

Besides a shell script can be 100s of lines, not very fun auditing it.

[rileymat2]

We could probably create a java applet or flash application that runs in the browser safely too!

That was more snark than HN likes, but it feels like forgetting promises of the past in a dangerous way.

[coldtea]

We do it everyday with Javascript in the browser, on, like, 10 orders of magnitude bigger frequency than we ever run Java Apples and Flash. The whole web commerce, banking, b2b, etc. depend on it. Imagine that, huh?

Is that enough snark?

Not to mention, if your problem is container breaking out, you have way way bigger problems that shell-script containers.

[soraminazuki]

I think you nicely summed up why we have a huge problem with the current state of things, both in the NPM and Docker ecosystem.

[coldtea]

One of these things is not like the other.

Also missed that my whole point was about CHECKING the container dockerfile - not running an off the net image as is.

Perhaps this lack of attention to context is why we have a huge problem with the current state of things, both in the NPM and Docker ecosystem.

[rileymat2]

Javascript has much smaller surface area to the system than a docker app. And we still find rowhammer type attacks.

[e12e]

> As long as it doesn't have access to outside of the container, who cares?

https://snyk.io/blog/cve-2024-21626-runc-process-cwd-contain...

[soraminazuki]

Also I can't imagine a real world scenario in which we can safely ignore what happens inside the container. Really reminds me of https://xkcd.com/1200/.

[flaminHotSpeedo]

Everyone running containers, particularly untrusted ones, should care because containers aren't a security tool and don't provide secure isolation.