I agree that this is a security problem that should be fixed.

The x-bit solution was apparently rejected by freedesktop.org, when this issue came up for the first time in 2006(!)

http://lists.freedesktop.org/archives/xdg/2006-April/006357.html

So I have another proposal, which does not need to alter the freedesktop specs, and this is that nautilus should warn the user about suspicious new desktop files. So how does nautilus tell trusty and suspicious launchers apart?

- Obviously, only application launchers are dangerous, so desktop files which represent (local or remote) folders and result in opening a new nautilus window are considered harmless.

- Launchers owned by root don't represent a problem as well. If an attacker could write files as root, he certainly doesn't need to use .desktop files to inflict damage.

- User-owned desktop files are tracked by nautilus, maybe using a hidden sqlite or db4 file in $HOME or something like that. The full path to the desktop file is saved there, as well as the Exec line. So overwriting existing desktop files with trojaned ones won't work either.

- Whenever nautilus *detects* a new (or altered) desktop file, which is not in the db, it alerts the user and asks what to do with that.

- Of course, if you use the standard graphical desktop tools to create launchers ("connect to server", "add launcher to panel", etc.) they would be added to the db automatically.

After reading the thread mentioned by Burkhard, I have some considerations:

1) The fact that uncompressing files can lead to creating files with the +x permission is a security problem per se, maybe graphical interfaces to archives should *not* preserve permissions by default (I think this is a pretty sane policy).

2) Using the previous security issue as an excuse to this security issue is simply unacceptable. These are different issues that need to be handled separatedly, since uncompressing a zip with an elf file with the +x bit set is a security problem. It is fairly sane to imagine that you should go and set the x bit by yourself (or go and mark the "preserve permissions" checkbox).

3) The biggest problem is *not* about .desktop files being able to show themselves as something different, but simply as that some random file that might be placed on your desktop by any number of applications (giver, pidgin, evolution, firefox etc) might be executed without anyone telling it is an executable.

4) I think .desktop files should not be handled specially in any way, if they are executable, they should be executed, if they are not they should be oppened with the viewer associated with that mime-type (which, I think, should be a nautilus properties dialog).

5) The problem of wine being invoked automatically for files without the x bit  by whatever application is a security bug of that application. This is also not an excuse for the .desktop issue.

6) Saying that the .desktop file format "is not a script" is simply missing the point on what a shbang is. A shbang doesn't say that file is a "script", it simply says that this file is handled by that interpreter, the contents of the file are then fully handled to the interpreter, that should then do something.

7) All the suggestions on how to "detect malware" is simply as fragile as any solution that is currently used on Windows. We have a filesystem with better semantics, so let's use it. That *do solves this specific problem*, it doesn't solve the problem of archive applications saving files with the x bit, but it does solve this problem.

8) The FDO spec about .desktop files do say that # is a comment, so a shbang in the start of the file is not breaking that spec.

9) The FDO spec doesn't regulate any permissions of the file, so requiring them to be executable does not break that spec.

10) As a transition scheme, accepting root-owned .desktop files as executable might be a good solution, but I'd rather convince the distros that on version X, Gnome won't accept launchers without the x bit.

11) Even if the FDO guys don't see this as a problem, GNOME can fix it by itself without breaking compatibility with the FDO spec (and probably causing a spec change in the mid-term).

I've just posted bug #572318 on the spirit of my last message

> 1) The fact that uncompressing files can lead to creating files with the +x
permission is a security problem per se, maybe graphical interfaces to archives
should *not* preserve permissions by default (I think this is a pretty sane
policy).

I think it's not. It would break stuff like ./configure-scripts and it would be very confusing, if its behaviour differs from the (posix-compatible) command-line tools. Not to mention that you would make those tools nearly useless for backup.

Normally there's no problem with extracting executables from an archive, as long as you can see that they are executables before you click them, and they can't cloak themselves as a pdf or jpg. 

I would oppose crippling otherwise useful applications, just because some standardization org invented one single, obscure type of files which could be harmful.

> 8) The FDO spec about .desktop files do say that # is a comment, so a shbang in the start of the file is not breaking that spec.
> 9) The FDO spec doesn't regulate any permissions of the file, so requiring them to be executable does not break that spec.

You are right. Such .desktop files themselves don't violate the spec. But nautilus denying to execute launchers, just because they have no x-bit and/or no shebang, does. ;)

I think making "preserve permissions" off by default is not making file-roller crippled. The option would be available in the "extract" dialog. Please see the  bug #572318 . 

The problem of file-roller (or any other archive application) creating files with +x bit set is absolutely not related to this bug, again, let's move the discussion about that issue to bug #572318.

Now, focusing on this specific issue:

So, we already agree that adding a shbang won't break the spec.
we also agree that adding +x won't break the spec.

Now, where in the FDO spec is the definition that the file must be executed even if it doesn't have the x bit set? Nowhere.

As a matter of spec-following, it's not illegal to require the +x bit as well as it is not illegal to execute without the +x bit. OTOH, it is a more general Unix policy, that files need the x bit to be executed.

I agree that I'm playing with words here, but so is everyone that is discussing this issue.

There is no excuse to execute a .desktop file without it having a x bit set. Not even the FDO specs. Only the backward compatibility with a bad implementation decision.

As a transition proposal, nautilus could look for .desktop files without the execute bit set and present a transition dialog allowing the user to review the .desktop files in its panels and desktop *if and only if* it is the first time the user runs a version of nautilus that doesn't run non-executable .desktop files, from that point on, nautilus would simply presents the "properties" dialog for non-executable .desktop files.

> Now, where in the FDO spec is the definition that the file must be executed
even if it doesn't have the x bit set? Nowhere.

I must admit, that I have not read the specification. ;)

But the whole point of a standard is, that you can create a standards compliant document, and then it can be used in every environment which follows the standard.  So ISVs can reasonably expect, that their desktop icons work in Gnome, KDE, Xfce, wherever, when they ship compliant .desktop files.

What you propose, is otherwise known as "embrace, extend, extinguish", and widely considered bad practice. ;)

> There is no excuse to execute a .desktop file without it having a x bit set.

Yes, there is. It is that the .desktop file isn't executed at all, but interpreted by nautilus and the contained command is executed. You can compare this with a browser plugin or firefox extension, which doesn't have the x-bit set either.

What I mean is that the fact that the FDO spec doesn't address the expected permissions of the file means that it is subject to interpretetation. I understand that under a "common law" sense, the fact that the current .desktop files doesn't have the x bit, means that the spec don't expect the x bit.

On the other hand, one can argue that the .desktop files break a far more old definition, which is that for files to be executed, they need a x bit. But this is "playing with words" again.

Changing a behavior without breaking the spec is not "embrace, extend, extinguish", it is plain merithocracy, someone taking a step forward so a proposed solution is evaluated, expecting for some comitee decision about the issue looks very much awkward.

Now I'd like to focus on the idea that a ".desktop file isn't executed". This is simply not true. It's not because the "desktop-launcher interpreter" is embedded inside nautilus that it changes that issue.

If we had an embedded Perl in nautilus, would that mean that it would make sense to run a file that looks like Perl without the x bit? It would be just the same thing.

It's not because the "Desktop Entry Specification" doesn't name itself as a "Programming Language" and the "Desktop Launcher" doesn't name itself as an "Interpreter" that it changes the very nature of what is happenning when you invoke it.

The .desktop file is the Desktop equivalent of a .sh in the console, specially because it is dead-easy to have an entire shell script inside the .desktop file.

There are embedded Perl or other language interpreters in other software like webservers, and you certainly need no x-bit on scripts to be interpreted by those servers. Perl itself interprets its own modules, and they don't carry the x-bit either.

However, there is also at least one case, where the x-bit is "abused" in a way similar to your proposal, and that is the "XBitHack" of apache mod_include.

Whatever - I am not skilled enough to deliver either solution, so I think I will quit the discussion for the moment and leave it up to the developers to deal with the problem one way or the other (or with another totally different but genius solution).

Let's simply agree, that there is a problem and something has to be done about it.

I've just created a proposed xdg-launch script that would be used as shbang for executable .desktop files.

That way, we could simply remove any special treatment of .desktop files
launching from nautilus, just making it execute it as a regular
executable file.

Then it can add a mime handler for the .desktop files so a properties
dialog is shown when a non-executable .desktop is clicked.

I mean, that and the migration process.

Created attachment 129172 [details]
Proposed xdg-launch script

Not sure if this is the right bug (else please point me to the right one), but the remote control tool we use at work stopped working with the last round of nautilus updates, e.g. since I was required to mark it as "trusted".

It's a .desktop executable you can get here: 
http://www.islonline.net/start/ISLLightDesk
http://www.islonline.net/start/ISLLightClient

Unfortunately, it isn't free software, however this is what my company has bought, so they want to use it... I can of course paste directly the "Exec" line of the .desktop file in the terminal, manually substituting %k, but if I can't have this working again before 2.26.0 gets deployed in Ubuntu 9.04, other users will complain and I'll have to revert to Windows for them.

Matteo,

Just deploy them with the +x bit set and it will work.

daniel

@Daniel: thanks, they were already. However, this seems it was just a temporary Ubuntu bug; with today updates it went away.

Fine, closing as for last comment.