investigate sandboxing for tasks on Linux (and maybe other platforms)

[thestinger]

In theory, at least on Linux, we can spawn the tasks without CLONE_VM for a private address space (as in fork). This would lay the groundwork for supporting sandboxing (seccomp, cgroups, namespaces) too.

I think this would be very useful for Servo, to sandbox spidermonkey. I don't know how viable this would be on other platforms where threads and processes aren't considered essentially the same thing by the kernel since it would likely be a huge hit to performance and memory usage.

[huonw]

Visiting for triage; would be a very cool feature to have built-in. "Nominating" for far-future.

[kmcallister]

@pcwalton and I talked about a design where the sandboxing spawn takes an extern "Rust" fn and does a fork + self-exec while passing the address of that function to the new process in an env var or something. Then the new process will start there rather than main.

This wouldn't have a shared exchange heap; instead you'd have a port/chan variant that uses UNIX pipes or something. The ability to send file descriptors through UNIX-domain sockets is potentially useful.

The killer demo here is something like

do spawn {
    unsafe {
        vulnerable_c_lib(shellcode);
    }
}

Run it and pop a shell. Then change spawn to spawn_seccomp, and watch the spawn'd process get SIGKILL and the parent see a usual task failure.

[thestinger]

Yeah, you wouldn't want to share memory directly between the tasks because you need to verify the integrity of any objects you receive to preserve the boundary.

[huonw]

triage, no change, although @thestinger wrote up something for servo here: https://github.com/mozilla/servo/wiki/Linux-sandboxing

[thestinger]

I think this is better suited to a third party library. The core functionality for Linux is here:

https://github.com/thestinger/rust-seccomp