"Name" key value in desk. entry spec collides with file names, could misguide users?

Diego Calleja diegocg at teleline.es
Tue Mar 15 23:05:31 EET 2005

El Tue, 15 Mar 2005 21:47:08 +0200,
Kalle Vahlman <kalle.vahlman at gmail.com> escribió:

> So what do you do with an executable that is not an executable? Admire
> its beauty in an hex editor? There is a way to be immune to this type

If it's malware downloaded from a web browser or saved with a mail client, yes,
that's the purpose

> of attacks, and it is educated users that DO NOT download shady
> materials. Making executables to not execute is not a cure, it is a
> short term treatment.

That'd fix everything indeed but I don't think educating all users is not possible, and if
free software continues rising we need to make it _difficult_ to fall in the hole. There're
already linux-based offices with uneducated people, and many people is targetting the
whole windows desktop world, so I don't think it's possible. In such "perfect world", 
activex wouldn't be the security problem it is - unsigned ActiveX controls always ask
you for confirmation, and educated people press always "cancel" and they've no
spyware issues. However most of the people press "OK" without reading what the
confirmation window says.

(Some people will say that it's activex fault by its design, but the fact is that there're
already some harmful java applets out there : Java allows to create applets which ej:
erase all your documents. Of course the sandbox stops that, but if you create such
applet, the Java VM ask you "do you want to run this harmful, unsigned applet?". If users
clicks "yes", the VM will allow the applet to delete all your documents, if not it won't
be allowed. Of course everybody press ok - it's a dialog box!! :)

> So the problem really is the executable mime type, NOT the .desktop
> spec. The spec is only a place to point your finger at.

Well, .desktop override everything, as long as they execute they can open whatever they
want, with the program they want, or anything. They're not "tied", like .jpg images can
be tied to gimp. They're too "special"

> Perhaps the way to get rid of the problem instead of the spec is to
> disallow launching .desktops with Exec-field inside the filemanager.
> This would zap the shortcuts on my desktop of course, but it has got
> to be worth it, right?

I actually like Waldo's proposal: require +x if you want your .desktop file to be
interpretated, if not, handle it as a normal file. The more I think about it, the more
I think the idea is right. .desktop files are themselves a "shell script" handled by
nautilus/konqueror, and should have the +x bit if they want to be "interpreted" (ie:
if they want to run something). Programs like evolution and firefox shouldn't save
things with +x privileges (unlike microsoft our software distribution channel is not
3rd party based and hopefully not many users will use apt/yum/portage, the ones
that really need to download executables can be instructed in the download page to 
enable the +x bit with konqueror/nautilus/chmod)

> The reason why this stuff is deadly in the windows world is that it
> can crap on your system settings, and essentially take over your
> machine. In Linux, it goes as far as your account lets it go (which

It's certainly possible to switch the (default) privileged user accounts to
unprivileged with a few clicks in windows, but that doesn't frees you from

Yesterday a friend got a worm, the worm itself don't uses *any* vulnerability. It just
uses your open messenger account to autosend itself as verysexy.pif. Your
contacts *trust* you and so they get the .pif file, as soon as it downloads they
try to open it and boom - they're infected and the chain starts again. This worms
can spread itself regardless of the privileges, and microsoft can't do much about
it: sending files is legal, and they can't stop them clicking on a .pif file (I bet that
in future releases of messenger they'll modify the client so that it doesn't accepts
.pif/.exe/.scr/etc files, it's the one thing they can do). If .pif files weren't always
executables like currently .desktop files are, this worm wouldn't have worked. 

More information about the xdg mailing list