[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 _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
