On Fri, 2016-12-16 at 14:38 -0800, Adam Williamson wrote:

Doesn't it mitigate the completely drive-by attack via Chrome and tracker metadata parsing, though? You can still exploit it, but not so seamlessly...right?

I think the attacker would win if the user ever visits his downloads directory in nautilus (triggering the thumbnailer) before deleting the file some other way. Still pretty bad.

On Sat, Dec 17, 2016 at 1:48 AM, Elad Alfassa elad@fedoraproject.org wrote:

On Sat, Dec 17, 2016 at 12:22 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:

...

On Fri, 2016-12-16 at 12:18 -0500, Matthew Miller wrote:

...

Can someone confirm that this update at least mitigates the issue highlighted in the blog?

The blog post indicates that it also targets the totem thumbnailer and totem itself, so no, improving tracker is not sufficient here.

Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org

wrt thumbnailers, I wanted to implement sandboxing for all of them using bubblewrap, see here https://bugzilla.gnome.org/show_bug.cgi?id=774497

but then I realized this will break thumbnailing support in flatpak'd applications, so I didn't implement it. We can try to use seccomp and such in every thumbnailers, but there are all kinds of thumbnailers a user can install (and they all parse untrusted files) so it sounds better if we implement some sort of a generic solution to sandbox *all* thumbnailers, instead of plugging holes in individual ones...

-- -Elad.

Also: perhaps it'll be easier to protect thumbnailers using a SELinux policy? I think that might be an "easy" solution at least for all the ones we have packaged in Fedora: we know where their executables are located, and the access they need is pretty simple: read-only for everything the user can access, no network, and write only to somewhere under /tmp... This should (in theory) be sufficient for most thumbnailers, apart from the gdkpixbuf ones which don't run in an external process (it should, at least theoretically, be easy to tear them out to an external process if needed, though)

On Sat, Dec 17, 2016 at 4:07 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:

On Sat, 2016-12-17 at 01:58 +0200, Elad Alfassa wrote:

...

Also: perhaps it'll be easier to protect thumbnailers using a SELinux policy?

There already is such a policy. Back when WebKit used libsoup's disk cache, you could visit your cache directory and the totem thumbnailer would immediately try to load remote resources off the Internet to thumbnail them. SELinux would block that. The security context of /usr/bin/totem-video-thumbnailer is system_u:object_r:thumb_exec_t:s0 so SELinux must be doing something there.

I think nobody ever fixed that.

Probably not doing enough. Or maybe the policy does allow the thumbnailer to launch subprocesses, but not much more than that, and if the blog author would've tried something more than just launching a calculator SELinux would've stopped them? I don't know.

On Sat, 2016-12-17 at 01:58 +0200, Elad Alfassa wrote:

...

This should (in theory) be sufficient for most thumbnailers, apart from the gdkpixbuf ones which don't run in an external process (it should, at least theoretically, be easy to tear them out to an external process if needed, though)

Guess what Bastien did that earlier this week! It landed in gdk-pixbuf 2.36.1 so I guess it's coming to F25. Note there are a bundle of more traditional security fixes that landed just after that release....

Awesome. I think that for thee short term, until we figure out what's the best way to actually sandbox thumbnailers (if that requires moving thumbnailers to a dbus service it's a lot of work that I simply don't have time for these days), we should use seccomp in all of them, at least the ones we ship by default. I might submit patches for this sometime this week, if I find the time to do that.

This of course wouldn't stop an exploit if the user actually *opens* the file in totem, but I don't think there's much we can do about that other than shipping totem (and all other apps too, of course) in a sandboxed flatpak.

Another thing to consider might be changing the way we package gstreamer plugins, so that obscure one such as the game music emulators will not be installed by default. However, that won't help much because an unsuspecting user might install them via the GNOME Software integration in totem, and would get pwnd anyway...

On Mon, Dec 19, 2016 at 07:43:35AM -0500, Bastien Nocera wrote:

As for the apps, when do we start shipping Flatpak'ed applications?

I'd like to see a plan for this too — Flatpak'd with sandboxing, ideally. We have the layered image build service for OCI/Docker containers, it'd be nice to fit Flatpak into that work.