Security warning about just created Xubuntu desktop shortcut

[Eero Tamminen]

Setup:
- Fresh Xubuntu 14.04 with all the available updates installed (as of 2014-06-08)

Use-case:
- Create desktop shortcut for Firefox (using content proposed by launcher creation dialog when writing Firefox to first edit box)
- Launch and close Firefox with that shortcut icon several times

Expected outcome:
- Firefox launches fine each time

Actual outcome:
- First time Firefox started fine, next times double clicking on the icon gives a security warning that it's from untrusted source/location

[Guido Berhoerster (gber)]

With Thunar 1.6 (bug #5012) there is a big security warning when trying to run .desktop files which do not have the executable bit set. This is currently not the case for .desktop files created by a user via exo-desktop-item-edit leading to reports like https://bugzilla.novell.com/show_bug.cgi?id=801326.

While exo-desktop-item-edit could be changed to set the executable bit by default, there does not seem to be a consensus among different DEs about this behavior so it is still problematic for .desktop files created by another DE, another editor or some installation script. I wonder if there isn't better solution to this or if we can at least get some common way of handling this among DEs?

[Eric Koegel (eric-koegel)]

*** Bug 10273 has been marked as a duplicate of this bug. ***

[Michael Orlitzky (michael-orlitzky)]

Created attachment 5561
Patch to make desktop files owner-executable

Unfortunately I don't think we can distinguish between a desktop file that some other tool created and one that was downloaded as, say, an email attachment. I figure the best we'll be able to do is make sure the user can execute the desktop files that he has created. If distros are installing them noexec, we can bug them. If XFCE's install scripts are doing it, we can fix that.

If we made non-executable files run arbitrary code, the cure would be worse than the disease.

This (very rough) patch will make new files created with exo-desktop-item-edit owner-executable. There's a case in an "if" statement that deals with remote files:

  /* for remote writes */
  ...

right below the place where I change the permissions. I have no idea what to do with it!

This patch only affects exo, but Jannis/Nick should see it here.

[Yves-Alexis Perez (corsac)]

See also bug #7554

[Guido Berhoerster (gber)]

(In reply to Yves-Alexis Perez from comment #3)
> See also bug #7554

I find that behavior also quite irritating and even dangerous when users unintentially execute a script rather than opening it in an editor (even though it does not have security implications like desktop files). Executable desktop files can (even if less likely) also be unintentionally executed and then interpreted by the shell.
Maybe desktop files and executables could be handled in a unified way and always require user interaction in form of a dialog that asks whether to open in an editor or to execute it. I think that's what Nautilus does (at least it did a while back).

[Yves-Alexis Perez (corsac)]

(In reply to Guido Berhoerster from comment #4)
> (In reply to Yves-Alexis Perez from comment #3)
> > See also bug #7554
>
> I find that behavior also quite irritating and even dangerous when users
> unintentially execute a script rather than opening it in an editor (even
> though it does not have security implications like desktop files).

What? No security implications?

> Executable desktop files can (even if less likely) also be unintentionally
> executed and then interpreted by the shell.

Sure.

> Maybe desktop files and executables could be handled in a unified way and
> always require user interaction in form of a dialog that asks whether to
> open in an editor or to execute it.

I guess so.

[Guido Berhoerster (gber)]

(In reply to Yves-Alexis Perez from comment #5)
> (In reply to Guido Berhoerster from comment #4)
> > (In reply to Yves-Alexis Perez from comment #3)
> > > See also bug #7554
> >
> > I find that behavior also quite irritating and even dangerous when users
> > unintentially execute a script rather than opening it in an editor (even
> > though it does not have security implications like desktop files).
>
> What? No security implications?

At least no through the same attack vector as the desktop files, browsers don't save files with the executable bit, so running a malicious script/executable would at least require an additional step such as extracting a tarball or similar.

[Steve Dodier-Lazaro (sidi)]

(apologies for the length)

Xfce products concerned:
- Thunar
- Xfdesktop
- xfce4-appfinder
- xfce4-session?

Files concerned (from now on called App files):
- Binaries with the exec bit
- Scripts with the exec bit
- Desktop files
- (future) Docker container files?

Relevant use cases:
- A: Users running apps directly by clicking on them from an "Apps" folder or the desktop (esp. Windows and OS X users)
- B: Developers/sysadmins who need to regularly edit .desktop files or scripts
- C: Users being tricked into downloading and executing code, without knowing what they're opening is code
- D: Users being instructed to download and run code (esp. scripts) which they believe is trustworthy and which they're usually not capable of analysing

Threat Model (informal):
The most common scenarii for attacks are drive-by downloads and existing malware adding binaries. Downloads can either be source files that target the app that opens them (very common) or App files (common too). Malware can be truly malicious software or benign software that has been compromised (including Xfce apps). It may want to create replacements for common programs and edit PATH, or add autostart apps. Without sandboxing virtually nothing can be done about it so it's offtopic for now. Note malware can set the exec bit itself.

Another scenario would be people posing as community helpers and posting (malicious) scripts. These scripts are quite common on the Linux world and everybody trusts each other. This is not a problem we can really address only technically...

Ideal solutions to untrusted downloads:
We can identify whether the source of a file is trusted by the user to provide services without hindering her security and privacy. We can then treat untrusted Apps either by means of warning or plugging on top of existing sandboxing software, along with appropriate notifications of the security status of the system and appropriate controls. So far this is highly speculative and requires development means and a design plan far beyond simply Xfce.

Ideal solutions to malware:
Apps should not be able to install other local apps without being given a special permission. Then Xfce can differentiate between how it treats App files for locally installed apps and App files that were created in other areas of the filesystem where existing apps can write.

Default behaviour expected by users:
The use cases call for a different interpretation of the cheapest interaction that can be performed on files. Obvious take away: we will need a settings UI to choose the default behaviour. Given that the potential user base has many more A users than B, and given no figures are available on the current Xfce userbase, I recommend that by default clicking on an App file is aligned on A and C. B is more of an edge case with users more competent to modify the default and D is a more problematic behaviour we shouldn't promote.

Default behaviour we should implement:
We can treat all App files of installed applications by executing them directly. We can define installed applications as those which have a .desktop file or a binary in @PREFIX@/share/applications/ and @PREFIX@/bin. Valid XDG prefixes are /usr...

[Simon Steinbeiß (ochosi)]

Thanks for the lengthy reply! I guess in an ideal world, we'd try to implement all of your suggestions.
However, I think what we need at this stage are a few practical easy-to-implement improvements on the status quo.

[Robby Workman (rworkman)]

*** Bug 11297 has been marked as a duplicate of this bug. ***

[Robby Workman (rworkman)]

First, is nautilus/gnome/whatever the file manager/desktop manager/desktopd of the month over there still making .desktop files mode 0644 if they're coming from e.g. online sources? I seem to recall that KDE was requiring this as well, but I won't swear to it.

Second, I'm inclined to go with "leave things as they are wrt xfce's setting them to 0644, in essence requiring them to be 0755 unless they're in a predictable/correct location." In other words, let's fix the issue raised in https://bugzilla.xfce.org/show_bug.cgi?id=11297 (if the user is intended to create a shortcut on the desktop, then mark it executable when it's created).

[Steve Dodier-Lazaro (sidi)]

The distinction between exec/non-exec bits is pretty irrelevant until sandboxing is fully deployed, to be honest. We cannot both provide security *and* a good UX for locally installed apps and .desktop files on the Desktop for now, so I'm tempted to go with good UX and revisit the decision later.

Some pseudo-code:
1a. Make a safe-list of directories with all of PATH, /usr/local/share/applications, /usr/share/applications, ~/.local/share/applications/, ~/Desktop
1b. Remove XDG_DOWNLOADS_DIR from the safe-list (to keep users who download to Desktop a bit safer)

2a. Whenever a bin/sh/desktop file is launched, retrieve location
2b. If location in safe-list, goto Execute (3)
2c. Else if exec-bit not set, goto Warning (4)
2d. Else if xfconf-key "script-launch-behaviour" set to Execute, goto Execute (3)
2d. Else if xfconf-key "script-launch-behaviour" set to Edit, goto Edit (6)
2e. Else if xfconf-key "script-launch-behaviour" set to Ask, goto ValidateExecute (5)
2f. Goto Warning (4) if the code branch ever reaches that point (secure programming, caters for future mistakes when refactoring)

3a. If script/bin, exec with a startup notification
3b. Else forward desktop file to utility that already handles it properly

4a. Warning dialog pops up, "**You are about to run a script(sh)/application(bin+desktop) of unknown origin.**" "It could be used to steal your data or break your computer. Only proceed if you trust the source of this file."
4b. "Help" button to Thunar doc (7)
4c. "Keep me safe" button that cancels -> make it explicit this is the safe option
4d. "Edit script/.desktop file/binary" button, see (6)
4e. "Run anyway" button that runs the file

5a. Info dialog pops up "**File XXX is a script/application**" "Thunar protects you from accidental script/application executions. You can change change this behaviour in <settings>."
5b. "Help" button to Thunar doc (7)
5c. "Cancel"
5d. "Edit script/.desktop file/binary" button, see (6)
5e. "Run" button

6a. This is both the logic to decide if we are able to provide an editor and to implement Edit, because I'm not sure how xdg-open handles scripts since they don't have a MIME Handler
6b. For script/desktop files, search for text/plain and text/xml handlers, for binaries application/octet-stream handlers
6c. Display "Edit" buttons only when a handler is found
6d. For "script-launch-behaviour" = Edit, when no handler is found, launch xdg-open to present the default app selection dialog so the user knows Thunar did its job

7a. Add a doc page to Thunar doc on the implemented behaviour
7b. Explain what warning protects users from, that users should ensure they trust sources of unknown bins and should be careful with pseudo/anonymous sources, should feel free to ask for help to community if unsure, recommend preferring packaged apps as they can be verified by the community
7c. Explain safe-list disables security warning
7d. Explain exec-bit disables security warning
7e. Explain settings keys and provide UI walkthrough to change settings

Please, your input on:
- Should "ValidateExecute" be the default for script/bin/desktop with exec-bit outside the safe-list? I argue that yes because it avoids accidental...

[Yves-Alexis Perez (corsac)]

(In reply to Steve Dodier-Lazaro from comment #11)
> The distinction between exec/non-exec bits is pretty irrelevant until
> sandboxing is fully deployed, to be honest. We cannot both provide security
> *and* a good UX for locally installed apps and .desktop files on the Desktop
> for now, so I'm tempted to go with good UX and revisit the decision later.

I disagree about “pretty irrelevant”. In a secure world you'd have complete W^X and thus would refuse to execute anything where the user has write access. But even doing that road, it looks logical (at least to me) to refuse to execute user stuff with no explicit execute permission.
>
> Some pseudo-code:
> 1a. Make a safe-list of directories with all of PATH,
> /usr/local/share/applications, /usr/share/applications,
> ~/.local/share/applications/, ~/Desktop

I don't think anything under $HOME should be really safe (even in $PATH).

> 1b. Remove XDG_DOWNLOADS_DIR from the safe-list (to keep users who download
> to Desktop a bit safer)

It seems that browsers now also set some extended attributes on downloaded files, so it might be interesting to support that (but I don't have any pointer here).

[Steve Dodier-Lazaro (sidi)]

(In reply to Yves-Alexis Perez from comment #12)
> (In reply to Steve Dodier-Lazaro from comment #11)
> > The distinction between exec/non-exec bits is pretty irrelevant until
> > sandboxing is fully deployed, to be honest. We cannot both provide security
> > *and* a good UX for locally installed apps and .desktop files on the Desktop
> > for now, so I'm tempted to go with good UX and revisit the decision later.
>
> I disagree about “pretty irrelevant”. In a secure world you'd have complete
> W^X and thus would refuse to execute anything where the user has write
> access. But even doing that road, it looks logical (at least to me) to
> refuse to execute user stuff with no explicit execute permission.

Essentially we have two threats: malicious downloads and malicious apps. If apps are malicious then anything $HOME is unsafe, and the exec bit is totally meaningless. If only considering malicious downloads, I could create a malicious archive with files that already contain the exec-bit set, so at the end of the day we're only protecting against standalone files on systems with a default umask. The distinction isn't particularly impressive. With proper (i.e., research grade for now and years to come) sandboxing on, you could tell from which app a file was downloaded, from which domain it came and whether you have a record of security issues with its advertised publisher. We're far from there yet. :-)

What I mean is that the difference *really does not set a security boundary*. It's purely heuristics-based, to match the most common scenario. On the day someone actively tries to distribute Linux malware, this reasoning will blow apart and we'll have to serve systematic warnings.

> >
> > Some pseudo-code:
> > 1a. Make a safe-list of directories with all of PATH,
> > /usr/local/share/applications, /usr/share/applications,
> > ~/.local/share/applications/, ~/Desktop
>
> I don't think anything under $HOME should be really safe (even in $PATH).

I agree with you, again it's a heuristics-based judgement which should be revisited as soon as evidence suggests our users are threatened and a warning could help. Hopefully basic sandboxing will be deployed by then so ~/.local/{bin,share} will not be writable by user apps.

>
> > 1b. Remove XDG_DOWNLOADS_DIR from the safe-list (to keep users who download
> > to Desktop a bit safer)
>
> It seems that browsers now also set some extended attributes on downloaded
> files, so it might be interesting to support that (but I don't have any
> pointer here).

Hmm, that's a good idea. Though, I'm not sure how many P2P apps/IM apps/browsers/direct downloads cohabit on the Linux ecosystem. Detecting file downloads at scale might be painful or unreliable.

In summary, for decision makers:
If Xfce wants to commit to security now in prevision for later, it should not include any $HOME paths into the safe-list, it should replace the "ValidateExecute" path with the "Warning" path and set "script-launch-behaviour" to ask/warn by default. My recommendation would be to be a bit nicer but to be ready to release stricter defaults in the future as facilities become available or risks become tangible. Of course we should suppo...

[Pliniusminor (pliniusminor)]

Speaking strictly from a user's point of view: it just makes no sense, to issue a warning and require the granting of executability rights, for the innocent act of launching an application by clicking a desktop shortcut. No sense at all....

This is needlessly confusing for beginners and very user-unfriendly. As far as I know, Xfce is the only desktop environment that does this.

It's no show-stopper bug of course, but it displeases some new Xfce users to the point that they stop seeing Xfce as a good alternative for other desktops.

Please remove this nasty "paper cut" from Xfce....

[Steve Dodier-Lazaro (sidi)]

(In reply to Pjotr from comment #14)
> Speaking strictly from a user's point of view: it just makes no sense, to
> issue a warning and require the granting of executability rights, for the
> innocent act of launching an application by clicking a desktop shortcut. No
> sense at all....
>
> This is needlessly confusing for beginners and very user-unfriendly. As far
> as I know, Xfce is the only desktop environment that does this.
>
> It's no show-stopper bug of course, but it displeases some new Xfce users to
> the point that they stop seeing Xfce as a good alternative for other
> desktops.
>
> Please remove this nasty "paper cut" from Xfce....

Please don't copy and paste comments across bug reports, and please make sure you're up-to-date with the discussion :-)

The current proposal I made is that there will never be any warning on the Desktop, unless it is also used as a Downloads directory (in which case no difference can be made between Downloads and app shortcuts.

Warning about the risks inherent to the execution of unknown software is certainly not a pleasant experience, but it remains a necessary first step to help our users build the right mental models of malware and adopt safer practices.

[Pliniusminor (pliniusminor)]

(In reply to Steve Dodier-Lazaro from comment #15)
> Please don't copy and paste comments across bug reports, and please make
> sure you're up-to-date with the discussion :-)
>
> The current proposal I made is that there will never be any warning on the
> Desktop, unless it is also used as a Downloads directory (in which case no
> difference can be made between Downloads and app shortcuts.
>
> Warning about the risks inherent to the execution of unknown software is
> certainly not a pleasant experience, but it remains a necessary first step
> to help our users build the right mental models of malware and adopt safer
> practices.

I apologize for the copy/paste. :-)

Your current proposal looks like a big step in the right direction. But please don't try to educate the Xfce users to the point that they simply leave and select another, more user-friendly desktop environment.

Xfce has great potential as "the" lightweight alternative to bigger desktops like Gnome, KDE, Cinnamon and Mate. In order to realize that potential more fully, Xfce shouldn't become less user-friendly, in my opinion....

That said: I appreciate your efforts and I'm glad to see that the Xfce project has become a lot more lively, in the last couple of days. Unfortunately I have no programming skills, so my contribution is limited to providing Dutch translations at Transifex.

Xfce is a great project, which deserves more market share than it has now!

[Steve Dodier-Lazaro (sidi)]

*** Bug 7596 has been marked as a duplicate of this bug. ***

[Langer Alexey (langer-alexey)]

Friends, why not just give the performance rights for all *.desktop files in the directory "/usr/share/applications/" ? On the desktop files are copied from this directory?

[Hjudt-l (hjudt-l)]

*** Bug 7554 has been marked as a duplicate of this bug. ***

[Manuel Grießmayr (dccoder84)]

I store all my browser bookmarks as .desktop files and to me it is very annoying to everytime click "Mark as executable". The user should have the option to check "Don't ask again for future .desktop files." and the user should be informed about the security issues. He should have the choice between better UX or better security. Of course the user should also be able to undo this setting. Even if we only have a hidden setting, this would be better than nothing. Is there a plan how to move ahead with this issue?

[Theo Linkspfeifer (lastonestanding)]

*** Bug 15573 has been marked as a duplicate of this bug. ***

[Bluesabre-1 (bluesabre-1)]

I just became aware of this discussion as I implemented the following change in Exo:

https://git.xfce.org/xfce/exo/commit/?id=8c8548d84fd0ca9454c894a2f2da7a9a0d6197c9

In this instance, the user is always creating the launcher, and confirming before the file is created. Once the launcher is created, it's marked as executable. This dialog is displayed when dragging a URL to the desktop or Thunar, and when creating a new launcher.

[Michael Orlitzky (michael-orlitzky)]

IMO the root of the issue is the abuse of the executable bit for things that aren't executable. I posted about this a few years ago, the last time a series of .desktop vulnerabilities came up:

https://www.openwall.com/lists/oss-security/2017/11/08/10

I'm only mentioning it here for posterity; I just realized that I never came back to comment on this bug.