Sandbox thoughts

[Andy Lutomirski <luto amacapital net>]

[I'm not a gnome-os subscriber.  Let's see whether this bounces as a result.]

Hi all-

I just read Alexander's blog post about Neverball in a sandbox.  Neat stuff!

Here are some thoughts, in no particular order:

 - seccomp.  Seccomp will help a lot, especially in avoiding attacks
against more obscure kernel interfaces.  There's a decent
blacklist-based sandbox I worked on here:

https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/supervisor.c%2B%2B

Ideally it would be a whitelist, not a blacklist, but this set of
filter rules blocked a whole bunch of kernel vulnerabilities that
showed up after I wrote the rules.

As on Linux 3.18 (IIRC), seccomp has reasonably low overhead.  (It was
terrible before that.)  If you try it and have issues, performance or
otherwise, please let me know.  On new kernels, the overhead should be
well under 100 cycles per syscall plus the filter execution time.

 - setuid / privileged helper.  Why do you need a privileged helper?
You should be able to do all of this using user namespaces.  The
Sandstorm code linked above does exactly this.

 - netns.  Having an IPv6 loopback is probably good, too.  You might
get this by default with no particular action required on your part,
though.

 - kdbus.  Why do you need kdbus?  Wouldn't a userspace proxy work
fine?  Even with kdbus, I imagine you're using the restricted endpoint
features, and I wasn't quite convinced that the design would allow
very flexible and clearly secure sandboxing.  If I were designing a
sandbox that used kdbus, I'd mount a fresh "domain" (aka kdbusfs) in
the sandbox and I'd still want to proxy everything explicitly.  That
way the sandboxed code could still use kdbus however it wanted.  What
has your experience using it been like?

--Andy