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?
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.
If you want to further lock this down, there are many tools such as apparmor and seccomp that you can add custom profiles with but a good starting point would be:
docker run --security-opt no-new-privileges --cap-drop ALL untrusted-image
adastra22•7mo ago
Telstrom90•7mo ago
adastra22•7mo ago
amluto•7mo ago
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•7mo ago
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•7mo ago
Too bad there's also:
Steal my credentials (temporarily, but still...) to access remote systems without restriction:
Access TCP and UDP ports without restriction, including anything exported by any other container I'm running, because Docker has no real security model Outright pwn me, but only if "entitiled":RainyDayTmrw•7mo ago
[1]: https://www.aquasec.com/blog/container-isolation/
dijit•7mo ago
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•7mo ago
elternal_love•7mo ago
eyberg•7mo ago
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•7mo ago
nyrikki•7mo ago
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.
dijksterhuis•7mo ago
so if you want sandboxing and proper isolation -- use a VM.
https://learn.microsoft.com/en-us/virtualization/windowscont...
nijave•7mo ago
There is some isolation but not complete isolation
bilbo-b-baggins•7mo ago
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...
lotharcable•7mo ago
Especially ones that utilize a lot of the "CI/CD" pipeline approach.
Lots of secrets getting pulled from various different places, access to testing environments and testing databases needed for unit testing, access to systems that deploy to testing and prod environments. Sensitive code and secrets from multiple applications being used in the same servers and build infrastructure, etc.
So even if you trust containers to containerize securely (which is a bad idea in practice) there are all sorts of holes being poked in them to allow them integrate and access things. Even during building and testing.
Most security effort for most organizations involve hardening parts of production systems that are exposed to users and/or the internet. This not only involves proofing code and setting up firewalls, WAF, and such things, but also monitoring and whatnot.
That is expensive and a lot of work to do, while in build environments it tends to be more slapped together and people ignore them until something breaks.
You have similar situations with backup solutions. People need backups to secure data from corruption or deletion and protect businesses that way, but seeing them as a potential security hole isn't really thought about in the same way as running a production web server. Again it is something that just enough effort is put into to make sure it works and little attention is given to it unless it breaks.