Bug 404750 - Thumbnails of files in vaults are unencrypted
Summary: Thumbnails of files in vaults are unencrypted
Alias: None
Product: Plasma Vault
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR grave
Target Milestone: ---
Assignee: Ivan Čukić
Depends on:
Reported: 2019-02-23 22:38 UTC by eemantsal
Modified: 2019-05-05 20:56 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.57


Note You need to log in before you can comment on or make changes to this bug.
Description eemantsal 2019-02-23 22:38:15 UTC
The thumbnails of files in KDE vaults (or any other encrypted folders and files) should not be stored in an unencrypted folder like ~/.cache/thumbnails, or if so, should be deleted after vault's unmount.
There's little point in keeping our private files in secure folders safe from eavesdropper eyes if in the end they all are "microfilmed" in the thumbnails folder, especially those in ~/.cache/thumbnails/large, which have a rather generous size. In the case of plain texts the thumbnail only shows the first lines, but images and other content are fully thumbnailed.

1. Mount some vault
2. Browse it with Dolphin, Gwenview, whatever program that makes thumbnails.
3. Close the vault

In ~/.cache/thumbnails new thumbnails of the vault's content have been created and are stored unencrypted.

Actually this is not a malfunction but a design flaw. But I guess that a nice expected result would be that 
these thumbnails were saved in the vault, perhaps a /thumbnails subfolder inside the vault's mount folder, so they are invisible until the vault gets mounted. Or maybe said thumbnails subfolder could be mounted also in ~/.cache/thumbnails -so the user could purge his image caché as easily as always- perhaps inside an mount subfolder with the same name of the vault -If vault "SecretCoffin" is mounted, then the folder ~/.cache/thumbnails/SecretCoffin is created and shows the encripted thumbnails. If "SuperSecretCoffin" gets unmounted, ~/.cache/thumbnails/SuperSecretCoffin becomes an empty directory or is deleted.
This would have the disadvantage of having this hypothetical encrypted thumbnails folder mounted twice, and the clarity gained on one side could add confusion on the other. I don't really know. I hope you, devs, will probably figure better solutions.

Linux/KDE Plasma: Gentoo, Plasma 5.15.1
(available in About System)
KDE Plasma Version: 5.15.1
KDE Frameworks Version: 5.55
Qt Version: 5.12.1

I think this issue should be taken rather seriously and urgently. It surprises me that nobody has reported this security flaw yet, which means that every user of Plasma's vaults who enables thumbnails is ignorant that they in reality have many of their encrypted information easily accessible to anyone who has access to their PC.
Comment 1 Ivan Čukić 2019-03-23 13:54:41 UTC
This will be remedied as soon as the patch to KIO gets through.
Comment 2 Ivan Čukić 2019-03-24 14:16:02 UTC
Git commit bc42a1b2f9138558eb0d3d33f70e0e416a5225ca by Ivan Cukic.
Committed on 24/03/2019 at 14:15.
Pushed by ivan into branch 'master'.

Don't create thumbnails for encrypted Vaults

This patch makes PreviewJob skip thumbnail generation on fuse.encfs and fuse.cryfs mounts.

Reviewers: davidedmundson, dfaure

Reviewed By: davidedmundson

Subscribers: broulik, kde-frameworks-devel

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D19979

M  +21   -0    src/widgets/previewjob.cpp

Comment 3 PhobosK 2019-05-05 16:53:00 UTC
Hi @Ivan Čukić,
This patch seems a rather drastic approach to the problem....
Yes it is the easiest way to address the problem, but not a user friendly one and cripples KDE functionality...It makes totally impossible to use preview on any file on encrypted volumes. It does even cripples gwenview browse mode... and many users would like to have previews even on encrypted volumes...

So is it possible for you or someone to think of a more user friendly way to cope with the issue?
For example isn't there a way to make KIO (thumbnails) generate previews/thumbnails and show them in dolphin/gwenview/etc but not store them on disk (maybe something using bSave or bNeedCache). Even if next time the user revisits the same folder to regenerate all from scratch?

Besides from a security point of view, once an encrypted volume is mounted, it is totally exposed to services and applications running under the user session - like baloo, tracker, kactivitymanagerd etc, - so in a way a total security fix is actually hard to achieve...

Comment 4 Ivan Čukić 2019-05-05 17:02:53 UTC
Hi Phobos,

The next patch will be dedicated to KIO thumbnailer not caching the thumbnails.

I agree this is a drastic measure. The aim is to have thumbnails disabled in dolphin and enabled in gwenview, but without caching.
Comment 5 PhobosK 2019-05-05 17:20:37 UTC
Thanks very much :)

But why disabled in dolphin? 
A use case like mine for example - where I have a lot of PDF and ODT files in the encrypted folder - and I can differentiate between them thanks to the thumbnails and the previews...

So could the aim be just a thumbnail/preview working in any KDE app but none of those to be cached anywhere? :)
Comment 6 Ivan Čukić 2019-05-05 17:24:22 UTC
I'll have to think about that. I understand the usability pov.

The reason why I'm leaning against it is that even if the thumbnails are not cached, all the files are decrypted (accessible to applications that can inspect RAM) and can potentially even end up saved on the swap drive.

When you open gwenview, you show intent that you want to see those files.
Comment 7 Nate Graham 2019-05-05 20:56:52 UTC
I'd like the thumbnails to be visible in Dolphin, too. For encrypted vaults, could we give KIO some extra smarts to store the thumbnails inside the vault itself rather than in the XDG thumbnails dir? People with extra super secure needs can always disable thumbnails (and probably already have).