GNOME Bugzilla – Bug 518757
support thumbnails on mounts / avoid leaking information from encrypted filesystems
Last modified: 2018-05-24 11:20:33 UTC
The thumbnail spec supports the notion of local thumbnail repositories http://web.archive.org/web/20070824034129/jens.triq.net/thumbnail-spec/local.html This is interesting to use on encrypted media to avoid leaking thumbnails of documents into $HOME which may be cleartext. In fact, as we do this today, this is somewhat important to fix as some people might call it a grave security bug. I've added the 'security' keywork just in case; feel free to remove it. Will attach patches against gio, gvfs and libgnomeui to implement this.
Created attachment 105952 [details] [review] gio patch There's room for optimization here.
Created attachment 105953 [details] [review] gvfs patch
Created attachment 105954 [details] [review] libgnomeui patch It'll only work on local mounts for now; didn't port the code over to gio just yet. It's an open question if whether we want to allow gnome_thumbnail_factory_lookup() to return an URI. E.g. "gphoto2://[usb:001,042]/.thumblocal/normal/51a95447c63733b6c892c322a9eae329.png". I don't know.
These patches combined plugs leaking information via thumbnails for LUKS volumes. Please consider these patches for GNOME 2.22. The thumbnailing spec needs revision (plus hosting on fd.o but that's another matter) to change the language such that it's allowed to populate .thumblocal on encrypted mounts (to avoid this security bug). I can bring that up on xdg-list. Also, there's some interesting applications of .thumblocal - the gphoto2 backend can use this to provide a fast path to thumbnails by providing a virtualized .thumblocal directory. When nautilus reads a thumbnail from there it can then save it in $HOME/.thumbnails. This provides an ultra fast path for thumbnailing as the gphoto2 backend can fetch thumbnails directly from the camera (it's part of the PTP protocol) - nautilus-cd-burner could include an option "[x] Include thumbnails on disc"
I read the spec like the .thumblocal directory is supposed to be in each folder, not in the toplevel dir. But its not very clear. But take this: > The filename of the thumbnail is the md5sum of the filename part of the URI. > Because the URI is possibly not constant, only the filename part of the URI > should be used, no directory or protocol parts. It says "no directory" parts. Anyway, we're very close to release and should focus on relese blockers, not feature creep.
(In reply to comment #5) > I read the spec like the .thumblocal directory is supposed to be in each > folder, not in the toplevel dir. But its not very clear. But take this: > > > The filename of the thumbnail is the md5sum of the filename part of the URI. > > Because the URI is possibly not constant, only the filename part of the URI > > should be used, no directory or protocol parts. > > It says "no directory" parts. Then the spec is broken and needs to be fixed. Obviously omitting the directory name is never going to work, not even for CD-ROM which is their canonical example. I think with "no directory" it means the directory parts leading up to the mount point. > Anyway, we're very close to release and should focus on relese blockers, not > feature creep. I can appreciate the fact we're close to a release and may want to punt this to 2.23. That's fine. But I really wish you didn't call a security bug that involves leaking information from an encrypted mount "feature creep". If you think about it, it's actually quite bad what we are doing...
(In reply to comment #5) > I read the spec like the .thumblocal directory is supposed to be in each > folder, not in the toplevel dir. Oh, I didn't get this impression from reading the spec at all. > But its not very clear. I agree. Maybe we should ask on xdg-list? Certainly the spec needs to work for encrypted mounts otherwise we can't fix this bug.
Actually thinking about it having .thumblocal in each folder might make more sense. I'm thinking mostly about shiny future storage pool based file systems where you can e.g. select that only folder ~/Documents is encrypted (things like ZFS or btrfs comes to mind). (also, this approach means that the get_thumbnail_attributes() in glocalfileinfo.c would be slightly faster; no need to get the enclosing mount so we'd save a lot of stats going up the chain.) I'm fine with redoing the patches to do this; would mean that we'd need g_file_is_encrypted() in addition (or replacing) g_mount_is_encrypted(). Anyway, need to clarify the thumbnail spec first; I'll ask on xdg-list. So this is definitely 2.23 stuff. Thanks for your feedback so far.
I've asked here http://lists.freedesktop.org/archives/xdg/2008-February/009274.html
> Actually thinking about it having .thumblocal in each folder might make more sense. I don't know. The current approach has the advantage that clearing your thumbnail cache is very simple, and you never leak information to other users through shared files. If all users share a .thumblocal folder with lax permission rights, isn't this even worse? Note that we also leak information through our metadata machine: By seeing what URIs have already been browsed by the user, you can conclude what subfolders exist in a directory that cannot be listed (has -x set). Of course, that's also available through shell history, but many shells allow to exclude commands from being stored in the history. best regards, Christian Neumair
No need for a g_file_is_encrypted() call. Just use g_file_query_filesystem_info on the path. I call it "feature creep", because this is something we already do today, so keeping doing it is not a regression. And while its not ideal its far less of a problem than some other issues we have like things crashing for normal users that we need to fix to be usable at all. Anyway, there are reasons for not allowing writing to the .thumblocal directory. There are generally permissions problems for it so that you often can't write to it. And if you do then you might have to make the directory world writable which is bad. Also, if multiple people have write access to a .thumblocal directory then you can place files there that are autoloaded by other users, which is a possible slight security issue. You also have to make the thumbnails world readable, as otherwise only one user can read them, but other users would use the same name and can't thumbnail. However, being world readable means you leak a thumbnail of a file that may not be world readable itself. Even if you propagate the actual file permissions to the thumbnail that info may go stale if the file later changes permissions. Its also very hard to clean these directories up, as they are scattered all over the place and the files in them are not always deleted when the corresponding file is deleted (especially since the dirs are hidden). A better approach would be to store the thumbnails encrypted in $home, and store a random cookie used for the encryption in the encrypted filesystem (.thumbcookie?). Only if you can read the cookiefile on the encrypted filesystem can you decrypt the thumbnail.
Bug 381910 is closely related to this (duplicate?)
*** Bug 381910 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/127.