On Sat, Dec 17, 2016 at 1:48 AM, Elad Alfassa <elad(a)fedoraproject.org>
wrote:
On Sat, Dec 17, 2016 at 12:22 AM, Michael Catanzaro
<mcatanzaro(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)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)
--
-Elad.