[cc'ing tracker-l...@gnome.org] Hi Hanno
On Mon, Dec 5, 2016 at 1:03 PM, Hanno Böck <ha...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
