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.

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

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...


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)