Security issue with .desktop files revisited

[Egbert van der Wal]

>>> We need to fix the evaluation semantics of Exec, not write a bunch of
>>> easily-avoidable workarounds.
>>>       
>> 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
>>
>> Exec=/opt/cxoffice/bin/wine --workdir "C:////Program Files////QuickTime
>> " --check --cx-app "C:////Program
>> Files////QuickTime////QuickTimePlayer.exe"
>>
>> (all on one line of course) while not allowing
>>
>> Exec=rm -rf /
>>     
>
> While fixing the evaluation semantics of the Exec field would of course
> be the best solution, it might be too complicated to get this right.
> But, as suggested earlier, we could add some kind of signature to the
> .desktop files, which allows applications to tell whether a .desktop
> file can be trusted or not.
>
>   

And who is going to attach these signatures?

I would say a more appropriate approach would be to classify the command
in a few cases:
1) The command executed is a program/script in the user's home-directory
or some other user-writable location(which increases the risk of it
being malware)
2) The command executed is an program/script in /bin, which are
generally more dangerous than other executables(rm, mv and others reside
there)
3) The command executed is a program/script in /usr/bin, which are
generally(but not always ofcourse) safer to use.

This would of course introduce a need to extract the real command from
the exec-line in the .desktop file but that shouldn't be too hard.

Anyway, I think +x is more a nuisance than improved safety. As the
situation now is, .desktop files aren't more executable than .sh files
without a +x bit set; those too can be executed by doing 'sh script.sh',
same as .desktop files with a different parser.

-- Egbert