Re:A lesson in dockerizing shell scripts
by iforgotpassword on Saturday February 03, 2024 @02:45PM
(#39244037)
> That's why you grab their dockerfile and build it yourself.
Then you still didn't audit anything. What you need to do is inspect the docker file, follow everything it pulls in and audit that, finally audit the script itself that the whole container gets built for in the first place. Whereas when you just download the script and run that directly, you only need to do the last step.
Re:A lesson in dockerizing shell scripts
by beeboobaa on Saturday February 03, 2024 @05:25PM
(#39245388)
All of that is the same as a shell script, yes. A dockerfile is essentially just a glorified shell script installing dependencies, which you'd otherwise just be doing yourself.
Re:A lesson in dockerizing shell scripts
by coldtea on Saturday February 03, 2024 @06:58PM
(#39246002)
>Then you still didn't audit anything. What you need to do is inspect the docker file, follow everything it pulls in and audit that
You don't need to audit anything it pulls in INSIDE the container. Who cares? Just what kind of access it gives the container to the host.
Re:A lesson in dockerizing shell scripts
by stirfish on Saturday February 03, 2024 @07:04PM
(#39246048)
This sounds like fine a way to mine Bitcoin for someone else
Re:A lesson in dockerizing shell scripts
by tomjakubowski on Saturday February 03, 2024 @07:47PM
(#39246343)
You can use quotas to mitigate that risk, and monitoring to discover it. You'd be monitoring CPU usage anyway, whether or not you build your own images or write your own Dockerfiles.
Re:A lesson in dockerizing shell scripts
by coldtea on Saturday February 03, 2024 @09:09PM
(#39246847)
The whole point is that you checked that the container gets no access to the network.
Not to mention why wouldn't you let a shell script container keep running?
Yeah, people don't seem to actually care. The Bitnami images were quite popular, but looking inside it they all just pull random tarballs from their server, and nothing seemed to indicate where those things came from.
I assume you mean auditing docker images. In which case, sure. That's why you grab their dockerfile and build it yourself.
Though using dive[1] it's pretty easy to inspect docker images too, as long as they extend a base image you trust.
[1] https://github.com/wagoodman/dive