[STE-104] sandbox: file system isolation
achille-roussel opened this issue · comments
The current sandbox only applies to the network layer (in addition to the isolation provided by WebAssembly modules), the file system is fully shared with the host, and there are a few concerns with this approach.
Task processes may concurrently modify the file system
While individual WebAssembly module instances are single-threaded, timecraft may execute multiple task processes in parallel. The task processes have no mechanism for synchronization, they could corrupt the state on disk by unknowingly making changes to the same directories.
Untrusted code should be forbidden access to the host files
When running untrusted code in task processes, the processes should not be allowed to access the host file system without explicitly being allowed to. In some cases, even simply allowing writes to the file system may not be acceptable and the untrusted code should be given read-only access only.
File system isolation per process
A default where task processes are given a dedicated directory they cannot escape from could be a good model to start from, as it is always easier to relax restrictions than take things away.
To retain the model where the entry point is a trusted application that behaves "as if" it was being run directly by the operating system, it might be meaningful to retain exposing / as the default behavior in the case of the main process.
Parallel with containers and the OCI model
If we used container images as a distribution mechanism for WebAssembly modules, a parallel could be made with how those images embed a file system representation. It is a superset of the model where each task process receives a dedicated directory to work on, but instead of being empty, the content is initialized to the files bundled in the image.