Re: Sandboxing thumbnailers/file preview code

Hey Steve,

On Fri, 2014-05-23 at 17:14 +0000, Dodier-Lazaro, Steve wrote:

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]