Bug 404750

Summary:	Thumbnails of files in vaults are unencrypted
Product:	[Plasma] Plasma Vault	Reporter:	eemantsal <infmtk>
Component:	general	Assignee:	Ivan Čukić <ivan.cukic>
Status:	RESOLVED FIXED
Severity:	grave	CC:	nate, phobosk
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://commits.kde.org/kio/bc42a1b2f9138558eb0d3d33f70e0e416a5225ca	Version Fixed In:	5.57

Description eemantsal 2019-02-23 22:38:15 UTC

SUMMARY
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.

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

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

EXPECTED RESULT
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.

SOFTWARE/OS
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

ADDITIONAL INFORMATION
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

Summary:
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

https://commits.kde.org/kio/bc42a1b2f9138558eb0d3d33f70e0e416a5225ca

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...

Thanks

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).