Re: Sandbox thoughts

[Michael Catanzaro <mcatanzaro gnome org>]

On Wed, Feb 18, 2015 at 3:11 AM, Alexander Larsson <alexl redhat com> wrote:

Cool. I'll be sure to steal liberally from this. Some comments: // AIO is scary. Really? This seems like it is something that could be useful to apps, is it not?

Also, vmsplice seems like it could be useful too.

My impression of the sandstorm sandbox is that the goal is to limit rarely-used kernel interfaces simply to reduce the kernel attack surface. That's a good idea for high-risk applications that are constantly exposed to malicious input (e.g. your web browser) and that know they don't use the aio syscalls. I'm not sure if that's an appropriate strategy for GNOME to follow. It's already going to be a fair bit of work to port your existing application to use an app bundle, and the more syscalls we block, the harder that will be.

It has some things you don't, such as: module calls, iopl, swap*, kexec, open_by_handle_at.

I'm using seccomp filters to sandbox the WebKit web process on Linux. I'm experimenting with a whitelist approach now, but it is extremely fragile: Fedora will update a dependency I've never heard of to use a new syscall I've never heard of (recent example: libxshmfence now uses memfd_create), then the web process is borked. Obviously random dependency updates will not be a problem with app bundles, but I would still recommend a blacklist instead. I would just filter out a few syscalls that app bundles should really not be using -- the systemd list looks good -- and call it a day. We'll still have gone from allowing an app to trivially access and exfiltrate the user's files, to requiring the app to exploit a kernel zero-day to do so. That seems like pretty good progress to me.

As a side note, all three of our sandboxes are using libseccomp because it is nice. That's what GNOME should use.< /div>