5

The freedesktop organization defines the standard for .desktop files. Unfortunately it defines not the permissions of the file (see freedesktop mailinglist) and software is distributed with

a) executable .desktop files
b) non executable .desktop files
c) mixed a) and b) in one software package. 

This is not very satisfying for Linux distributors, who aim to provide a consistent system. I want to use the broad audience of sx, to find out

what advantage has a .desktop file without execution bit? Is there any reason for not having all .desktop files executable if the filesystem alows it?

Are there known security problems? Are there programs which have difficulties with executable .desktop files?

2 Answers 2

10

One obvious reason a .desktop has not necessarily the executable bit set is these files were not intended to be executable in the first place. A .desktop file contains metadata the tell the desktop environment how to associate programs to file types but was never designed to be executed itself.

However, as a .desktop file indirectly tell the graphic environment what to execute, it has an indirect capacity to launch whatever program is defined in it, opening the door to exploits. To avoid malicious .desktop files to be responsible to the launch of hostile or unwanted programs, KDE and gnome developers introduced a custom hack that somewhat deviates the intended Unix file execution permission purpose to add a security layer. With this new layer, only .desktop files with the executable bit set are taken into account by the desktop environment.

Just turning a non executable file like a .desktop one to an executable one would be a questionable practice because it introduces a risk. Non binary executable files with no shebang are executed by a shell (be it bash or sh or whatever). Asking the shell to execute a file which is not a shell script has unpredictable results.

To avoid that issue, a shebang needs to be present in the .desktop files and should point to the right command designed to handle them, xdg-open, like for example Thunderbird does here:

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Name=Thunderbird
GenericName=Email
Comment=Send and Receive Email
...

In this case, executing the .desktop file will do whatever xdg-open (and your Desktop Environment) believe is the right thing to do, possibly just opening the file with a browser or a text editor which might not be what you expect.

2
  • 3
    That's rather the result of a longer debate as I pointed out here (btw, the accepted answer to that question is utterly wrong...) and it is also implemented in GNOME (and possibly other DEs but I wouldn't know). However, these "security measures" (i.e. shebang and chmod+x) do not apply to desktop files that come from upstream and are placed in $XDG_DATA_DIRS/applications only to local files placed in $XDG_DATA_HOME/applications Jun 25, 2017 at 13:16
  • @don_crissti Thanks for the information, answer adjusted.
    – jlliagre
    Jun 25, 2017 at 16:34
2

Security considerations of type 1 desktop files

Desktop files are textual configuration files that are used by file managers and window managers. As noted above, their format is specified by a FreeDesktop standard:

Both the KDE and GNOME desktop environments have adopted a similar format for "desktop entries", or configuration files describing how a particular program is to be launched, how it appears in menus, etc. It is to the larger community's benefit that a unified standard be agreed upon by all parties such that interoperation between the two environments, and indeed any additional environments that implement the specification, becomes simpler.

The current FreeDesktop specification lists three different kinds of desktop entries:

This specification defines 3 types of desktop entries: Application (type 1), Link (type 2) and Directory (type 3). To allow the addition of new types in the future, implementations should ignore desktop entries with an unknown type.

The security implications of Application (type 1) desktop files have been discussed at length multiple times on the FreeDesktop mailing list:

I noticed quite a while ago that .desktop files as specified by freedesktop.org open a window into GNU/Linux for a whole range of viruses and trojans. I think that this has been discussed before. I see that the issue has not been resolved so I'd like to suggest a way to resolve it.

Conventionally files downloaded from the Internet cannot simply be "clicked" to run them under unix/GNU/Linux, the execute permission must be granted (or an installer used or archive extracted).

--- Sam Watkins, ".desktop files, serious security hole, virus-friendliness", April 2006 (LWN summary)

In the event that the launch would have been forbidden based on the preceding restrictions, the user is given the option of automatically making the service executable and then launching. Although this part makes me a bit queasy I think it's the best option to easily allow existing Desktop icons, panel launchers, etc. to continue to work.

--- Michael Pyne, ".desktop file security", February 2009

To the best of my knowledge, there is only one CVE associated with desktop files: CVE-2017-14604.

GNOME Nautilus before 3.23.90 allows attackers to spoof a file type by using the .desktop file extension, as demonstrated by an attack in which a .desktop file's Name field ends in .pdf but this file's Exec field launches a malicious "sh -c" command. In other words, Nautilus provides no UI indication that a file actually has the potentially unsafe .desktop extension; instead, the UI only shows the .pdf extension. One (slightly) mitigating factor is that an attack requires the .desktop file to have execute permission. The solution is to ask the user to confirm that the file is supposed to be treated as a .desktop file, and then remember the user's answer in the metadata::trusted field.

There's more background here if you're curious:

nautilus: CVE-2017-14604: .desktop files can hide malware in Nautilus

There is a bug in Nautilus that makes it possible to disguise a malicious script as an innocent document, like a PDF or ODT, that gets executed when the user opens it.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860268

The exploit I created is a file called sgos_handbook.pdf.desktop (though I could have named it malware.desktop and it would have looked the same in Nautilus). Here’s what’s inside of it. Note that the name is set to sgos_handbook.pdf, and the icon is gnome-mime-application-pdf which is the default icon for PDFs in Subgraph — these two things make it so you can’t tell that this isn’t a PDF when viewing it in Nautilus.

https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/

Here's a simplified version of the proof-of-concept malicious desktop file:

[Desktop Entry]
Name=my-file.pdf
Exec=sh -c "xeyes"
Type=Application
Icon=gnome-mime-application-pdf

The icon looks like a PDF file, but rather than opening a PDF file, it runs a shell script that runs xeyes. Of course, xeyes could just as easily be rm -rf $HOME or something similarly malicious. This has since been fixed by requiring the user to actively trust the desktop file before the file manager displays the custom icon and name.

Other purposes of desktop files.

However, desktop files are used for more than associating mimetypes and launching applications.

Let's start with type 3, which are desktop entries but are .directory files, not exactly .desktop files.

Directory files (type 3)

Directory files (type 3) are mainly used for creating categories in hierarchical menus; that's what the Categories key is for in type 1 desktop files. For example, consider this example from /usr/share/desktop-directories/Utility.directory:

[Desktop Entry]
Name=Accessories
Comment=Desktop accessories
Icon=applications-utilities
Type=Directory
X-Ubuntu-Gettext-Domain=gnome-menus-3.0

So if a desktop file has "Utility" in its Categories key, it will show up in the Utility menu subdirectory.

The Dolphin file manager also uses directory files to e.g. enable/disable thumbnail previews of images.

As far as I know, there is no reason for .directory files to be executable.

Link-type desktop files (type 2)

Link-type desktop files can point to arbitrary URLs. This makes it easy to store relevant links or URL in a given directory.

Currently, most file managers require link-type desktop files to be executable before opening the URL. This makes sense, because although opening a URL is not equivalent to running arbitrary code, file:// URLs can point to executables, and URLs in general can be malicious.

file URLs

For example, in Ubuntu the example-content package adds a type 2 desktop file similar to this in the home directory:

[Desktop Entry]
Type=Link
Name=Examples
Comment=Example content for Ubuntu
URL=file:///usr/share/example-content/
Icon=folder

Double-clicking on this desktop file in a file manager will navigate to the /usr/share/example-content/ folder.

Link-type desktop files can also point to files. For example, here's one that opens the manual for the LaTeX hyperref package:

[Desktop Entry]
Type=Link
Name=hyperref manual
URL=file:///usr/share/doc/texlive-doc/latex/hyperref/manual.pdf

http/https URLs

Link-type desktop files can also be used to open HTTP URLs in the browser. For example, here is a desktop file linking to this page:

[Desktop Entry]
Name=What is the advantage of .desktop files without executable bit set?
Type=Link
URL=https://unix.stackexchange.com/questions/373239/what-is-the-advantage-of-desktop-files-without-executable-bit-set

This isn't the most cross-platform option, but it is widely used.

other URLs

Link-type desktop files can contain arbitrary URLs; as long as there is a handler registered for the URI scheme, they will work. For example, a desktop file could contain a mailto: URL:

[Desktop Entry]
Name=Email Linus Torvalds
Type=Link
URL=mailto:torvalds@transmeta.com

or an smb:// URL:

[Desktop Entry]
Name=My Samba share
Type=Link
URL=smb://username@server/my-samba-share

or a special file-manager URL like this:

[Desktop Entry]
Name=Trash
Type=Link
Icon=user-trash-full
EmptyIcon=user-trash
URL=trash:///

or this:

[Desktop Entry]
Name=Recent documents
Type=Link
Icon=document-open-recent
URL=recent:///

Related links.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.