Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building untrusted container images safely at scale

depot.dev

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Building untrusted container images safely at scale

#11

Post by vbezhenar »

dijit wrote: post #9
adastra22 wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Building untrusted container images safely at scale

#12

Post by elternal_love »

vbezhenar wrote: post #11
dijit wrote: post #9

Earlier quoted context omitted.

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.

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…

Linux kernel code has had many zero-days bugs and will continue to do so. Kernel programming is _incredibly_hard and unforgiving.

Re: Building untrusted container images safely at scale

#13

Post by CamouflagedKiwi »

I'm a bit disappointed. I thought the article would have some discussion on how to actually build untrusted container images in a safe way, but it is really just about how to connect to the Depot API and have it do it for you. I imagine there must be something inside there that answers that part (from some of their other articles, maybe that's BuildKit? unsure).

Re: Building untrusted container images safely at scale

#14

Post by eyberg »

vbezhenar wrote: post #11
dijit wrote: post #9

Earlier quoted context omitted.

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.

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…

> 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.

Re: Building untrusted container images safely at scale

#15

Post by nijave »

adastra22 wrote: post #4
Telstrom90 wrote: post #3

Earlier 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.

The network isn't usually isolated. It build file can arbitrarily switch to the root user

There is some isolation but not complete isolation

Re: Building untrusted container images safely at scale

#16

Post by PhilipRoman »

vbezhenar wrote: post #11
dijit wrote: post #9

Earlier quoted context omitted.

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.

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…

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.

Re: Building untrusted container images safely at scale

#17

Post by yedidmh »

Anyone have advise or links for how to dynamically run untrusted code in production? Specifically NodeJS.

It looks like the isolated-vm package is the go-to, but understandably it prevents things like fetch or being able to import packages.

I’m thinking to use docker and have a single base image that exposes an API that will take an arbitrary string, check for and install imports, then eval (eesh) the code, but before going down the road of implementing it myself and going crazy over properly securing the containers I’m thinking that there has got to be some prior art. How are Codesandbox et al doing it?

Re: Building untrusted container images safely at scale

#18

Post by yjftsjthsd-h »

yedidmh wrote: post #17

Anyone have advise or links for how to dynamically run untrusted code in production? Specifically NodeJS. It looks like the isolated-vm package is the go-to, but understandably it prevents things like fetch or being able to import packages. I’m thinking to use docker and have a single base image that exposes an API that will take an arbitrary string, check for and install imports, then eval (eesh) the code, but befor…

What is your threat model / what are you trying to stop from happening?

Re: Building untrusted container images safely at scale

#19

Post by nyrikki »

vbezhenar wrote: post #11
dijit wrote: post #9

Earlier quoted context omitted.

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.

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…

Namespaces are not a security feature, they are... namespaces.

In k8s as an example, if you share your PID namespace in a pod, which is a simple config option, you can arbitrarily enter other pod member FS tree with /proc/PID/root, only protected by Unix permissions.

Without seacomp, capabilities, SELinux etc... anyone who can launch a docker container can use the --privlaged flag and change host firmware or view any filesystem including the hosts root.

Focusing on namespace breakout only misses most of the attack surface.

Re: Building untrusted container images safely at scale

#20

Post by weitendorf »

yedidmh wrote: post #17

Anyone have advise or links for how to dynamically run untrusted code in production? Specifically NodeJS. It looks like the isolated-vm package is the go-to, but understandably it prevents things like fetch or being able to import packages. I’m thinking to use docker and have a single base image that exposes an API that will take an arbitrary string, check for and install imports, then eval (eesh) the code, but befor…

I recommend gvisor: https://gvisor.dev/

If you want to learn more about this subject the keyword you’re looking for is “multitenancy”

Docker’s container runtime is not really a safe way to run untrusted code. I don’t recommend relying on it.

Also, why would an isolated vm prevent fetch? You can give your users NAT addresses to let them make outbound network calls. I am putting the finishing touches on a remote IDE that does exactly that.

Post reply on HN