On Feb 18, 2015 7:00 AM, "Michael Catanzaro" <[email protected]> wrote: > > 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.
FWIW, I don't think sandstorm's sandbox has caused a porting problem at all yet. Desktop do different kinds of crazy things though. > >> It has some things you don't, such as: module calls, iopl, swap*, kexec, open_by_handle_at. > I only worried about things usable without global caps. > > 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. > True. Sandstorm tries to avoid those zero-days, too, which is a stronger goal. > As a side note, all three of our sandboxes are using libseccomp because it is nice. That's what GNOME should use. I have very mixed feelings about this. On the one hand, libseccomp is much easier to use than the competition. On the other hand, it's extremely inflexible. For example, filtering socket(2) is conceptually easy, but libseccomp can't use a syscall nr blacklist and a socket arg0 whitelist. (I may have that slightly wrong. It's been awhile since I wrote that bit of sandstorm code.) --Andy
_______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
