Building untrusted container images safely at scale
1–10 of 29 posts
Re: Building untrusted container images safely at scale
#2I'm confused--what's the security risk in building a container?
Re: Building untrusted container images safely at scale
#3I'm confused--what's the security risk in building a container?
You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Re: Building untrusted container images safely at scale
#4I'm confused--what's the security risk in building a container?
You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Inside the container though. The whole point of which is that it sandboxes and isolates the running code.
Re: Building untrusted container images safely at scale
#5Earlier quoted context omitted.
You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Inside the container though. The whole point of which is that it sandboxes and isolates the running code.
Maybe the default form of RUN is kinda sorta safe [0].
How about ADD? Or COPY? Or RUN —-mount=type=bind,rw…?
Over the last ten years or so we’ve progressed from subtle-ish security holes due to memory unsafety and such to shiny tools in shiny safe languages that have absolutely gaping security and isolation holes by design. Go us.
[0] There is some serious wishful thinking involved there.
Re: Building untrusted container images safely at scale
#6Earlier quoted context omitted.
You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Inside the container though. The whole point of which is that it sandboxes and isolates the running code.
This blog post[1] explains why that is not a safe assumption.
Re: Building untrusted container images safely at scale
#7[deleted]
Re: Building untrusted container images safely at scale
#8I'm confused--what's the security risk in building a container?
Fundamentally building a container involves running a container - each layer is executed in turn as a temporary container.
The same risks that running an unknown container has - are had by building one.
For reference there have been quite a few CVEs related to container escape: https://www.paloaltonetworks.com/blog/cloud-security/leaky-v...
Re: Building untrusted container images safely at scale
#9Earlier quoted context omitted.
You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Inside the container though. The whole point of which is that it sandboxes and isolates the running code.
Containers in linux are primarily a shipping method (as Docker themselves try to inform you with the visual of a shipping container).
Just like real shipping containers, dangerous things inside can leak out - the isolation is not foolproof by any means, in fact if someone has the express wish of violating the isolation boundary it's barely an inconvenience.
Re: Building untrusted container images safely at scale
#10Earlier quoted context omitted.
You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Inside the container though. The whole point of which is that it sandboxes and isolates the running code.
containers are not virtualization. they only provide lightweight isolation as they share the host kernel.
so if you want sandboxing and proper isolation -- use a VM.
https://learn.microsoft.com/en-us/virtualization/windowscont...