Re: Sandboxing thumbnailers/file preview code

[Bastien Nocera <hadess hadess net>]

Hey Steve,

On Fri, 2014-05-23 at 17:14 +0000, Dodier-Lazaro, Steve wrote:
> Hi,
>
>
> I've discussed with a few people recently on IRC about providing file
> previews in my sandbox-traversing File Choosers or in Allan's new
> Content Selection Dialogs, and also about running untrusted
> thumbnailers for use in Nautilus. I'm curious whether the file preview
> back-end could reuse thumbnailers and if custom file preview functions
> could be entirely replaced with standalone thumbnailer executables.

They cannot. The thumbnailers don't use any UI widgets, and provide none
of the necessary niceties to be usable as file previews. What you might
think as usable when previewing a PDF will completely fall apart when
previewing a video. There's also no "thumbnailer" for audio :)

> In an OS with sandboxed apps, one would really want to also sandbox
> thumbnailers: they run with the desktop environment's privileges and
> could potentially steal every file they're given (or more). I've had a
> quick glimpse at the GNOME Thumbnailer and it seems very easy to
> sandbox it. Instead of directly launching the untrusted thumbnailer,
> you'd give its path as a parameter to a generic Sandboxed Worker.

There's already some code in Fedora to use SELinux to provide some
minimal sandboxing of thumbnailers, not allowing some of them to write
anywhere but in the thumbnail directory for example.

> The worker could be a well-known D-Bus name or user systemd service
> that sets up a Docker/LXC container, makes a read-only bind of the
> input file's path and a write-only bind to the output file's path. It
> could have a switch just like systemd services to remove networking,
> and possibly start with very a limited system interface (using
> seccomp2, with options to allow extra syscalls depending on the
> worker's task).

You're getting deep into the technical implementation here, and I'm not
sure that should be done before defining the necessary interface. FWIW,
you don't need bind mounts to do this, you'd pass a read-only fd through
D-Bus, and avoid all kind of side-effects.

But that would mean that thumbnailers that use network information to
provide a thumbnail wouldn't work (downloading game or video covers for
example), those that use local databases wouldn't work either (like
audio file covers cached with libmediaart not being accessible to the
thumbnailer), etc.

I think it's important to list all the possible types of thumbnailers,
which accesses they need, and then discuss the possible implementations.
<snip>

Cheers