Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 17459 ideas, 107690 comments, 2263278 votes
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas
Idea #18028: Focus on security of .desktop files

Written by Ivo Georgiev the 14 Feb 09 at 08:23. Related project: Gnome. Status: New
Rationale
The .desktop files introduce a lot of problems - users can execute code without knowing what they do.
For example, they can receive the .desktop file on their email, and it's not required to give it execute permissions to run it.
In Gnome, there is a really big issue: .desktop files in ~/.local/share can overwrite the menu entry of some .desktop files in /usr/share/applications. For example, you have Synaptic. The run command specified in the .desktop file placed in /usr/share/applications is "gksu /usr/sbin/synaptic". A virus can copy this .desktop file to ~/.local/share/applications and change the run command to:
gksu /usr/sbin/synaptic. So, the user thinks that he is starting synaptic, but he is executing bad code as root as well as synaptic.
In KDE (tested in 3.5.10) there is another issue, that is fixed in Gnome: KDE doesn't check for MIME type and extension conflicts, so the user might download a file with a .pdf extension (for example), the file can have a icon of a pdf file (since it's a .desktop file, custom icon is easy to put), and click on it, thinking that it's a pdf file. But the file might execute malicious code and also copy itself in the KDE/Gnome autostart directory, or made to be run with root privileges when starting something with gksu for example.

If voting negative, please post a comment.

76
votes
up equal down
Solution #1: Basic security fixes
Written by Ivo Georgiev the 14 Feb 09 at 08:23.
1. Files in /usr/share/applications in priority in Gnome (they can overwrite the entries from ~/.local/share/applications).
2. MIME type/extension conflicts checking in KDE (like the Gnome's one)
3. Don't use gksu. To start, make a control panel. It will be started with a single command, without requiring root privileges. Then, it reads some files placed in /etc/control panel name/ (that users have no permission to modify) and creates a menu of those items. Like the Mandriva Control Center for example. It will require root privileges only if the user wants to run something. This way, a unprivileged user can't modify what will be run as root if you click at one of this menu items in the control panel.
136
votes
up equal down
Solution #2: Require executable permissions for the .desktop files to be run
Written by Ivo Georgiev the 14 Feb 09 at 08:25.
If the .desktop file has +x permissions, then it should be run. Else, it should be taken as a normal text file.

Also, it might not require +x permissions if the file is placed in /usr/share/applications, so it won't require re-packaging of the packages that contain .desktop files.
The .desktop files that you already have (for example on ~/Desktop) should be given +x privilege when the new version of application that manages .desktop files (nautilus in Gnome) is installed (through it's install script in it's package).
-22
votes
up equal down
Solution #3: Add an overlay icon
Written by viraptor the 20 Feb 09 at 17:44.
Simply add a small icon in the corner of the original one - the way windows shortcuts work.

It's the main idea that users run launchers, so blocking that in any way will just cause problems in normal use.

---
I wonder why this solution is voted below 0. Anyone cares to share?

Propose your solution

Attachments
No attachments.


Duplicates


Comments
cheesehead (Brainstorm moderator) wrote on the 15 Feb 09 at 13:26
This seems like a security bug more than an idea.

Ivo Georgiev wrote on the 15 Feb 09 at 13:48
"2. MIME type/extension conflicts checking in KDE"
Yes, you are right - that's a security bug. But I'm sure the rest is a suggestion rather than a bug.


Post your comment