.desktop file security

[John Tapsell]

2009/2/24 Alexander Larsson <alexl at redhat.com>:
> On Sat, 2009-02-21 at 18:07 -0500, Michael Pyne wrote:
>> Hi all,
>>
>>
>>
>> I'm just writing to let you know that I'm working on changing the
>> handling of .desktop files for the next major version of KDE. The work
>> itself is being tracked on kde-core-devel but a synopsis of the plan
>> is:
>>
>>
>>
>> When launching a .desktop file (which I'll refer to as a service), if
>> any of the following conditions are true, the launch is permitted:
>>
>>
>>
>> 1. The service is executable by the user
>> 2. The service is owned by root (to handle the common case of
>> system-installed files)
>> 3. The service is contained in a standard service directory. Right now
>> this means "xdgdata-apps" in addition to standard KDE service
>> locations.
>
> I'm doing something like this in gnome. ATM its just doing 1 and 3. What
> is the common usecase for 2? Note, that my changes don't affect general
> launching of desktop files in things like the menus, only those from the
> file manager, and only for application launchers (not e.g. uri links).
>
> Furthermore, I'm also doing:
> 4. Don't allow sniffing of desktop files, always require a .desktop
>   extension.
> 5. For untrusted desktop files, don't show the custom icon and display
>   name specified in the desktop file.
>
> With this in place you can always detect when something weird is going
> on by seeing the ".desktop" file and the standard icon for a launcher
> instead of a faked icon/name.
>
>> If the file is made executable automatically it is given a
>> "#!/usr/bin/env xdg-open" header as well if it did not already have a
>> #! header so that running the file from the command line will do the
>> right thing.
>
> While this is a "neat trick" I don't really think its a good idea.
> First of all it will conflict a bit with mimetype sniffing (of course,
> this is disabled in the common file case as per above, but its useful in
> e.g. a text editor for selecting syntax highlighting rules).

It's dangerous not to.  If it's marked as executable, and you execute
it, it will try to be parsed by bash.  Most of the time this will just
generate lots of "file not found" errors as bash tries to understand
it, but it seems pretty dangerous to rely on this!



>
> Secondly, I've never ever heard any request for being able to launch
> desktop files from other places, and in fact if we believe there is a
> (small) risk in executing desktop files, why do we want to unnecessarily
> enlarge the scope of this risk?
>
> And Thirdly, spawning via xdg-open is generally not a good way to handle
> desktop files. That way you can't e.g. apply startup notification, focus
> stealing prevention, file argument expansion, etc. There is also the
> risk that some app will accidentally launch the desktop file by spawning
> a lot of unnecessary stuff instead of just using the right APIs to
> launch desktop files that handles the stuff I listed.
>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>