I’m writing a server that allows people to write and run Julia programs in the cloud (similar to Repl.it).
What are some tips for sandboxing Julia so that programmers can’t trash the server?
- How do I redirect stdin/stdout?
- Should I create a custom version of Sys.jl with appropriately sandboxed functions? Or is there another technique?
- Is there a way to recycle the Julia process (if I call jl_init a second time will that reset the process to a pristine state? Or will global variables from a previous run still be set?)
I’m using C++ and Windows.
I appreciate any info or suggestions. Thanks!
1 Like
Would Docker be an option for you?
Thank you, yes, that could work, but wouldn’t I still need to trap outbound C-calls? For example, what if a Julia program tries to call a Docker DLL inside the container? Wouldn’t it be able to call Docker APIs and thus break out of the container? [Correct me if I’m wrong, please.]
I am not a security expert, but a user inside a Docker container should in principle only be allowed to access resources (e.g. ports, directories) mounted into the container.
However, there may be unknown security gaps in Docker, therefore it is best practice to use a non-root user in the Docker container (like in the Pluto image plutojl/pluto).
The security could potentially increased more using rootless Docker or a VM running the container, but I do not know if this is required.
1 Like
BTW, another possibility is to use the AppContainer feature of Windows: AppContainer for Legacy Applications - Win32 apps | Microsoft Docs
That seems to be more light-weight than Docker (since it works at the process level, rather than creating a full virtual environment).
In any case, it sounds like isolating via external tech (whether Docker or whatever) is better than trying to change the Julia runtime. Thank you for that suggestion.
Docker is only inefficient on Windows, whereas on Linux it’s practically free (it’s a few extra checks and lookups in the kernel, but shouldn’t be significant for most applications). Also, aside from security vulnerabilities in Docker itself, or privilege escalation bugs in the Linux kernel, containers are (by default) isolated from each other and cannot interfere, aside from using up resources like CPU and RAM (which Docker can be configured to limit, and you should do for your usecase).
2 Likes
On Windows, the new Docker WSL2 backend should be more efficient than the old HyperV backend. However, there is probably still more overhead than for Linux, but I do not know if this is significant for most use cases.
1 Like