.desktop file security

As most of you may have seen by now, foobar had made a post 10 days ago called “How to write a Linux virus in 5 easy steps.” That blog post was later covered on Slashdot and LWN, and describes the lack of security around .desktop launcher files. These .desktop files do lots of things, but one of their most prominent uses is in program launching.

Why are they needed? Well, they give a lot of extra metadata to executable programs, such as the icon to show, the friendly name, i18n translations, program working directory, whether a terminal-viewer should be launched in association, etc. Ever since their introduction, a .desktop file has been able to complete launching its associated program without being executable (that is, without have the +x bit set on the file for POSIX systems).

foobar makes a good point that in such a situation .desktop files are hardly any different than .vbs files in their effect if they were to be transported over email, and even if a .desktop file extension is not used, if the file “looks like” a .desktop file it will be handled as such. (For instance, on my KDE trunk desktop a .desktop file will be found out with a different extension or no extension, unless the fake extension is a known mimetype (like .jpg -> image/jpeg))

So this past week after some prompting by John Tapsell reminding us that we can’t drop the ball again I’ve been working on making .desktop files more secure. The issue is that we can’t simply require +x and see what happens, as even the installed menu icons in Kickoff are .desktop files, not to mention shortcuts on the Desktop and in the panel.

The alternative we hit upon in kde-core-devel was to allow .desktop file execution in the following cases:

  • If the .desktop file were owned by root (i.e. part of a standard system installation)
  • If the .desktop file was installed as part of the desktop environment (that is, it is from a known location for services, applications, and XDG-compliant applications. These correspond to the “services”, “apps”, and “xdgdata-apps” parameters to kde4-config –install). This allows for KDE installations to $HOME for instance.
  • Finally, having the file be executable by the user always allows the launcher to run.

Unfortunately this still leaves the problem of what to do with launchers on the desktop or in the panel. Going forward we will need to make such .desktop files executable when they’re created but users who are upgrading would all of a sudden lose their custom launchers if that was all we did.

So in addition to the lockdown code I’ve been working on a reliable means of giving the user the option of automatically “fixing” the .desktop file and continuing on with execution. Doing this would make the file executable, and add an appropriate #! header if one wasn’t already present. (The interpreter used for .desktop files is /usr/bin/env xdg-open).

This is an example of a dialog that would pop up for such a file (“mileage tracker.desktop”):

Dialog security popup example for launchers

The text isn’t set in stone yet (i.e. please suggest something better ;), I’m trying to make it descriptive enough to be useful without making the text so long as to simply lull the user into clicking “continue”.

One thing I haven’t done yet is to touch base with the XDG mailing lists to see if this requires revision to the specification (that way we don’t unintentionally break GNOME/Xfce/etc. apps on KDE, and don’t have ours broken). Mostly this was a matter of time — I already have little of it so it hasn’t quite percolated up in my priority list yet.

You can see my latest patches on the kde-core-devel mailing list. If you see any issues please don’t hesitate to email me or otherwise let me know sooner rather than later so we can either get them fixed or verify that it’s not an issue.