Trusting .desktop files
Fabian Vogt
fabian at ritter-vogt.de
Fri Feb 10 18:56:14 UTC 2017
Hi,
The reddit post "How to easily trick $FILE_MANAGER users to execute arbitrary code"
(https://www.reddit.com/r/linux/comments/5r6va0) spawned a discussion about .desktop files.
This is normally just a minor security issue as it requires manual user interaction. However,
Plasma's ineffective countermeasures give the user a false sense of security and that's the main
reason why I think it needs to be fixed correctly.
Dolphin is not affected by the issue in most directories, as .desktop files are shown with their
extension by default. Plasma's desktop folder is, however, and so extraced .desktop files from
archives for instance can look exactly the same as a text file (icon) called README (Name property).
This got fixed with
771e57f3b2c19f4e6f867c01c2457ec87531b4cf '[Folder View] show script execution prompt when clicking item'
but that in turn caused every application shortcut on the desktop to open a confirmation box first,
for untrusted .desktop files even two! ("Open/Execute?" and "Do you trust this?")
kbroulik worked around this by disabling the prompt for files in the desktop:/ location:
https://phabricator.kde.org/D4534
However, that basically reverts the fix and the security issue is there again, as the marker for
trusted .desktop files (as defined by KDesktopFile::isAuthorizedDesktopFile) is the executable bit.
That can be faked easily and is thus totally useless. .desktop files are not executable by themselves
as they have no shebang, thus it's also wrong.
What I'm proposing instead is to keep a list of trusted Exec= values and ask the user for confirmation
everytime a .desktop file with an unknown Exec= gets opened. Advantages:
- (Minor, does not usually happen) Changing Exec= revokes the trustedness.
- Copying .desktop files just works. Currently DnD'd .desktop files from /usr/share/applications/
onto the desktop are untrusted by default.
- The prompt shown when opening an untrusted file specifically shows only the Exec= value.
So it's also the Exec= value the user trusts and not the .desktop file.
- Cannot be faked by archives.
As Exec= can also contain relative paths, the working directory needs to be accounted for as well.
Thoughts, suggestions?
Cheers,
Fabian
More information about the Kde-frameworks-devel
mailing list