gaol crashes when starting a Sandbox

[covercash2]

i'm trying to use gaol to sandbox a fuzzer for ion.

i'm new to sandboxing and fuzzing, so bear with me.

anyway, here's the full stacktrace: pastebin

the fun parts are:

'main' panicked at 'assertion failed: unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0'

and

'main' panicked at 'assertion failed: libc::read(pipe_fds[0], &mut grandchild_pid as *mut i32 as *mut c_void, mem::size_of::<pid_t>() as size_t) == mem::size_of::<pid_t>() as ssize_t'

i'm a little hazy on what a namespace is supposed to be in this context. i've seen other threads that say that i need a kernel compiled with certain flags. i've seen threads from 2016 that reference this same stacktrace but with no solution.

the crash happens when i call sandbox.start(command). i'm unable to match the result. it just fails the assertions and closes.

my kernel:
Linux dirt 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux

i've also testing this on arch linux with the latest kernel. i can grab that too if it'll help, but i'm away from that machine.

i can't reproduce the error on my macbook however:
Darwin mymacbook 15.6.0 Darwin Kernel Version 15.6.0: Sun Jun 4 21:43:07 PDT 2017; root:xnu-3248.70.3~1/RELEASE_X86_64 x86_64

i would just run it on my macbook, but afl-rs has an issue with mac that hasn't been resolved.

i may be stuck in an x-y problem. any help is appreciated.

[ebkalderon]

I'm seeing this exact same error on my Arch Linux box:

thread 'main' panicked at 'assertion failed: unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0', <redacted>
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'assertion failed: libc::read(pipe_fds[0], &mut grandchild_pid as *mut i32 as *mut c_void,
           mem::size_of::<pid_t>() as size_t) ==
    mem::size_of::<pid_t>() as ssize_t', <redacted>
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I'm not really sure what's happening here either.

EDIT: Seems that Arch Linux is configured without CONFIG_USER_NS, which is a required kernel flag for this library (servo/servo#12778). In order to use Linux namespaces correctly, you have to run the sandbox process with root privileges.

[ebkalderon]

Seems like the Arch Linux maintainers recently chose to enable unprivileged namespaces with kernel version +5.1.8, meaning that gaol now works on that platform out of the box! I've also tested Bubblewrap and Bastille on my machine, and I can confirm they all appear to work correctly.

@covercash2 Now that I've been delving into sandboxing with unshare(2) and clone(2) with my own Rust sandboxing library, I understand now better what the panic messages in your original post represent. In that case, Arch Linux was not configured to have unprivileged namespaces by default, causing the call to libc::clone() to fail an assertion, which in turn caused the forked child process to fail another assert because the pipe that the parent and child were using to communicate was broken.

This isn't a bug with gaol per-se, but rather its UX could be significantly improved. For example, gaol could check whether user namespaces are supported on Linux at runtime and have SandboxMethods::start() return an Err if the feature is not available instead of relying on an assertion, so programs relying on gaol don't suddenly crash.

The reason why you couldn't reproduce the issue on macOS is because that platform uses sandboxd to achieve separation, which is an entirely different sandboxing API than what Linux uses.