4 ms·

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

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.

adastra22 1y ago
Inside the container though. The whole point of which is that it sandboxes and isolates the running code.
- amluto 1y ago
  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.
  - ptx 1y ago
    > Or RUN —-mount=type=bind,rw…? This seems to be pretty safe, according to the docs, if I understand them correctly. A bind mount can only mount "context directories" and the rw option will discard the written data, it says.
    - amluto 1y ago
      No way, you're right, they actually tried to make it kind of sensible. Too bad there's also: Steal my credentials (temporarily, but still...) to access remote systems without restriction: RUN --mount=type=ssh Access TCP and UDP ports without restriction, including anything exported by any other container I'm running, because Docker has no real security model RUN --network=host Outright pwn me, but only if "entitiled": RUN --security=insecure
- RainyDayTmrw 1y ago
  This blog post[1] explains why that is not a safe assumption. [1]: https://www.aquasec.com/blog/container-isolation/ https://www.aquasec.com/blog/container-isolation/
- dijit 1y ago
  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.
  - vbezhenar 1y ago
    I don't think that's the whole story. There's no documented way to escape the container. The kernel provides namespace isolation which should be foolproof by design. You might argue, that there were many bugs which allowed to escape the container and probably more bugs will be found in the future. However it does not mean, that it's fair to call it "inconvenience". I don't know any zero-day bugs in Linux and probably neither you. And it would take me a lot of effort to even attempt to find one.
    - elternal_love 1y ago
      Linux kernel code has had many zero-days bugs and will continue to do so. Kernel programming is _incredibly_hard and unforgiving.
    - eyberg 1y ago
      > should be foolproof by design. I think this is a core reason why containers have such a horrible security track record. They weren't made by design. One of the large problems is that there is no "create_container(2)". There are 8? different namespaces in conjunction with cgroups that make up "containers" and they are infinitely configurable. This is problematic and a core reason why we see container escapes almost every other month. Just look at user namespaces - some people use them and some people don't, but it was just a few months ago when multiple bypasses were published for them.
    - PhilipRoman 1y ago
      No company today will let you run your own code on their server if the only thing that's sandboxing it are containers. On the other hand, every VPS provider happily lets you do whatever you want inside their VM/hypervisor. This should tell you all you need to know about the security guarantees of Linux containers compared to hypervisors.
- dijksterhuis 1y ago
  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/windowscontainers/about/containers-vs-vm https://learn.microsoft.com/en-us/virtualization/windowscont...
- nijave 1y ago
  The network isn't usually isolated. It build file can arbitrarily switch to the root user There is some isolation but not complete isolation

adastra22 1y ago

Inside the container though. The whole point of which is that it sandboxes and isolates the running code.

amluto 1y ago
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.
- ptx 1y ago
  > Or RUN —-mount=type=bind,rw…? This seems to be pretty safe, according to the docs, if I understand them correctly. A bind mount can only mount "context directories" and the rw option will discard the written data, it says.
  - amluto 1y ago
    No way, you're right, they actually tried to make it kind of sensible. Too bad there's also: Steal my credentials (temporarily, but still...) to access remote systems without restriction: RUN --mount=type=ssh Access TCP and UDP ports without restriction, including anything exported by any other container I'm running, because Docker has no real security model RUN --network=host Outright pwn me, but only if "entitiled": RUN --security=insecure
RainyDayTmrw 1y ago
This blog post[1] explains why that is not a safe assumption. [1]: https://www.aquasec.com/blog/container-isolation/ https://www.aquasec.com/blog/container-isolation/
dijit 1y ago
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.
- vbezhenar 1y ago
  I don't think that's the whole story. There's no documented way to escape the container. The kernel provides namespace isolation which should be foolproof by design. You might argue, that there were many bugs which allowed to escape the container and probably more bugs will be found in the future. However it does not mean, that it's fair to call it "inconvenience". I don't know any zero-day bugs in Linux and probably neither you. And it would take me a lot of effort to even attempt to find one.
  - elternal_love 1y ago
    Linux kernel code has had many zero-days bugs and will continue to do so. Kernel programming is _incredibly_hard and unforgiving.
  - eyberg 1y ago
    > should be foolproof by design. I think this is a core reason why containers have such a horrible security track record. They weren't made by design. One of the large problems is that there is no "create_container(2)". There are 8? different namespaces in conjunction with cgroups that make up "containers" and they are infinitely configurable. This is problematic and a core reason why we see container escapes almost every other month. Just look at user namespaces - some people use them and some people don't, but it was just a few months ago when multiple bypasses were published for them.
  - PhilipRoman 1y ago
    No company today will let you run your own code on their server if the only thing that's sandboxing it are containers. On the other hand, every VPS provider happily lets you do whatever you want inside their VM/hypervisor. This should tell you all you need to know about the security guarantees of Linux containers compared to hypervisors.
dijksterhuis 1y ago
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/windowscontainers/about/containers-vs-vm https://learn.microsoft.com/en-us/virtualization/windowscont...
nijave 1y ago
The network isn't usually isolated. It build file can arbitrarily switch to the root user There is some isolation but not complete isolation