Recently a blogger who goes by the name "foobar" posted an article called "How to write a Linux virus in 5 easy steps", discussing vulnerabilities with the current handling of .desktop files. .desktop files are used in KDE, GNOME, and other environments complying with the freedesktop.org Desktop Entry Specification. They handle such diverse tasks as application launching, internet protocol handlers for KDE, desktop and panel/taskbar icons, and even plugins. These files provide some information regarding other files. For example, KDE executable files don't have icons embedded within them, so the information on what icon to use is contained in the associated .desktop file.
.desktop files are used for many things but one use in particular is of concern: launching applications. .desktop files can be used to launch a program, which is normally used to good purpose. But what if someone were to send you a .desktop file with a nice KSirtet icon that ran a malicious program and told you it was a game? Would you run it by mistake? Would a new Linux user run it by mistake?
The traditional defense against this has been requiring executable programs on POSIX systems to have an "executable" attribute set before the system would run it. .desktop files have never used the "executable" attribute, and desktop environments including KDE and GNOME do not enforce that rule. This was actually discussed on a shared desktop development list in 2006 but no action came of it. Now I figured it was time to change that.
So, the idea here is to bring .desktop file security up to the same level of other POSIX executables. This won't defend a user who blindly follows instructions from getting cracked, just as executable bits don't defend against that for malicious Perl or Python scripts.
My work has been in several areas:
- Requiring .desktop files to be executable before they launch a program.
- Changing KDE to make new Link to Applications correctly executable.
- Drafting ideas to allow current KDE users to safely upgrade.
- Drafting ideas to allow current .desktop files to be fixed.
- If the .desktop file is owned by root, allow. This exception covers most desktop environment files (such as a KDE installation to /usr). This is possible since a user unwittingly saving a trojan .desktop file won't be able to save it as root without additional action. (Remember, we're only defending against "click-through" cracking).
- If the .desktop file is installed in a standard KDE location, allow. This is required to allow users to install KDE to their home directory without root permissions. This is allowable because although it is possible to tell a user to navigate to a certain spot and save their file, users competent enough to run their own KDE in ~/ should not fall for it. Users not running a self-KDE will not be able to save into the KDE installation directory without additional action.
There is still the issue of what to do with custom launchers already created. After enabling the security there is no guaranteed way for KDE to tell apart user-created shortcuts from user-downloaded trojans. So, it was decided to add a method to explain what's going on and automatically fix the shortcut if necessary. (Other methods explored included an upgrade script which would "+x" (add the executable bit to) detected .desktop files automatically, but doing a thourough search would take awhile and have to start from /, not $HOME to accurately detect them all. In addition if the user already had trojans they'd be marked executable too!).
The dialog box used has gone through a few revisions:
It was recognized that this was not optimal however. The text was so long that the user was likely to simply click "Continue" and be done with it. Finally after some discussion with Celeste Lyn Paul and Tom Albers, Tom managed to reach into the root of the issue (does the user think they're running a program or not?), which led to the following mockup, which will probably be much closer to the final product after the design is worked up:
This will hopefully allow the user the opportunity to make a more informed decision without feeling they need to simply click "Continue", without breaking all of their existing program shortcuts. If the user chooses to continue then the service is automatically made executable to prevent the dialog from popping up again for the same .desktop file.
There is more to do of course. Alexander Larsson is working on the same issue with GNOME and has implemented code to show a generic icon and the actual filename for .desktop files that are not executable in Nautilus, and I'll probably see to it that the same thing happens in KDE to prevent deceptive .desktop files from causing confusion or damage. In addition, testing still needs to be done to make sure nothing else was inadvertently broken by adding more security. But this is a good start to restoring customary levels of security to KDE users.