Re: [Tracker] Tracker as a security risks

[Sam Thursfield <ssssam gmail com>]

[cc'ing tracker-list gnome org]

Hi Hanno

On Mon, Dec 5, 2016 at 1:03 PM, Hanno Böck <hanno hboeck de> wrote:
> I wanted to point out a recent blogpost by IT security export Chris
> Evans:
> https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html

Thanks for the link.

...
> While the bugs that evans points out have been fixed (and the gstreamer
> team has fixed a whole bunch of other potential security issues I
> reported in the past days, thanks!), the whole design of Tracker seems
> incredibly risky. It is certainly worthwhile trying to make the
> underlying software more secure, but having tried to do that before
> I find it unlikely that projects like gstreamer or imagemagick will
> ever be in a state where we can feel comfortable feeding them with
> untrusted files.
>
> The core problem here is that tracker automatically parses files of
> potentially unknown origin with parsers that haven't been built with
> security in mind. This happens without any sandboxing.

The design of Tracker takes the risks into account. Metadata
extraction is isolated in its own process (tracker-extract) which can
crash without (theoretically) causing any harm.

We could and should add more limits on that process to protect against
exploits in the libraries it uses for parsing. Here's a sketch from
memory of what the tracker-extract process needs access to:

* read access to the file it is parsing
* read/write access to the media-art cache (~/.local/cache/media-art)

It doesn't need network access, hardware access, or (I think) any
other filesystem access than what's listed above.

It does need read & write access to the Tracker database over D-Bus
(org.freedesktop.Tracker1), that's a bit of a risk which perhaps the
tracker-extract process could mitigate by running the actual parsing
in another separate process. This second process could be fed the
input file on stdin and could write the metadata it finds on stdout,
which would mean it needs no filesystem access other than the
media-art cache.

Are there any volunteers who have time to look at this? I'm not sure
the best way to implement it; SELinux, AppArmor or Capsicum would all
work but none of those are available on all *nix platforms. Or the
`bubblewrap` tool could be used, although I think that's also
Linux-only at the moment.

> I think there needs to be a wider discussion about this and the
> fundamental design choices done here need to be questioned.

What questions do you have in particular?

Sam