Security issue with .desktop files revisited

[Rodney Dawes]

On Wed, 2006-04-12 at 14:46 +0200, Francois Gouget wrote:
> In order to run an executable one must have the execute permissions for 
> that executable. Whether you like it or not .desktop files are 
> executables and, as such, running them ('opening' them in desktop 
> parlance) should require that you have the relevant execute permissions.
> 
> Requiring +x on .desktop files also makes it possible to add an emblem 
> to the icon of those that lack it, and/or to issue a warning when the 
> user tries to run them. Thus this also protects users from .desktop 
> files that have a misleading icon.

It doesn't prevent the .desktop file from having a misleading icon at
all. You're not changing the semantics of what goes in the Icon field.
You're simply requiring a user to do more work than is necessary, to
actually use their computer. And .desktop files are in fact data and
not executable scripts. Requiring +x just requires you to make them
behave more like scripts. 

> Sure there are many ways to make a .desktop file executable. But that's 
> completely besides the point, because once we require +x on .desktop 
> files they represent no more of a threat than shell scripts and ELF 
> binaries. So any solution to that particular problem must also take care 
> of those otherwise it is useless. By the way, such a solution exists, it 
> relies on Extended Attributes, and as has been said before will take a 
> long time before it can really be deployed.

What are you talking about? What solution?

> So to summarize the current situation:
>   * .desktop files are the only type of executable that can be run with 
> a single click immediately after download
>   * they can specify a misleading icon to fool the user

We need to fix the semantics of the Icon field as well. This is actually
easy to specify for common desktop applications. We can just rely on the
naming scheme for application icons that is in the Icon Naming
Specification, and specify the proper way to deal with types of .desktop
files which are not Type=Application as well, such as links to webdav or
smb shares.

> And after the we require .desktop files to have +x:
>   * .desktop files cannot be run without special action by the user
>   * .desktop files cannot rely on their icon to fool the user

Requiring +x on a desktop file a) doesn't solve the problem, and b)
certainly does not change what icon actually is set in the .desktop
file. Users are going to just get into the habit of always doing chmod
+x, as we have already been doing for perl/python/etc... scripts that
we download off the web.

> I don't see anything to be fixed in the 'evaluation semantics of Exec' 
> that would help solve this problem. Maybe if you have a concrete 
> proposal that can be discussed further. When writing your proposal, 
> please keep in mind that it must be flexible enough to allow stuff like

I don't mean to write a proposal to change the semantics of Exec. It was
a suggestion as a method for actually solving the real problem, instead
of just sticking our heads in the sand and pretending like the +x bit is
going to make all the problems go away. We need to either actually fix
the problem, or stop overreacting about it. A .desktop file that simply
removes all your files is not a realistic attack these days. One that
sends your private gpg/ssh/etc... data off to some remote site or sets
up your machine to be a relay for spamhosts or other attacks against
other people, are much more realistic. People are more interested in
stealing your data or using your machine for stealing other people's
data, than simply destroying your data any more. And these attacks do
not really make sense for someone to do with a .desktop file. Most users
run fairly insecure machines as it is. The .desktop file attack method
just does not seem all that realistic to me, and people on this list are
overreacting to the potential threat of it happening, and blindly diving
for some simple-to-implement method that will make it not particularly
any harder for an attack to still work, but will make you think the
problem is no longer there.

Setting +x is not a solution, it's a problem.

-- dobey