On Wed, Feb 18, 2015 at 3:11 AM, Alexander Larsson <[email protected]>
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.
_______________________________________________
gnome-os-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-os-list
