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?
*** Bug 10273 has been marked as a duplicate of this bug. ***
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.
See also bug #7554
(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).
(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.
(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.
(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, /usr/local and ~/.local/ on most *NIX OSes. Might want to include the "opt" ones as well though I'm skeptical. Some of these locations are writable by malware so for now I would recommend a Xfconf setting or a settings UI to disable default-execution for locally installed software. Standalone binaries/scripts/desktop files should be given a security warning. We need to tell users that they are about to let someone run code on their platform and damage could ensue. This protects the C group, educates the D group (if they read...) but of course pisses off the A and B group. Hence we also need to tell them how to intelligently get rid of this annoying warning! Again a setting should be provided to let B developers and advanced A users override the warning if it gets in the way of their workflow as they generally understand what code execution means. Warning goals: - Warn about unwanted executions WITHOUT WASTING THE USER'S TIME - Give users an economic incentive to install apps properly - Cover major use cases and PROVIDE ONLY ACTIONABLE ACTIONS Warning actions: - Let users run untrusted code if they feel like it - Provide a nice quick UX to untrusted executions in sandboxes (i.e. the warning gives a "Run in sandbox" button when sandboxes become available) - Help users install their apps by providing a button/link that either redirects to a helper (better) or automagically "installs" the app - Help users get back to safety and move on ("Cancel" or "Keep me safe" button...) What about locally installed apps? We should have a logic to differentiate between Apps that are installed and Apps that aren't. Installed Apps should always have a desktop files in @PREFIX@/share/applications/. Note that locally installed apps should be on the rise as Fedora seems to want to use Docker app bundles that can be locally installed too. If a dev installs a local app in a specific prefix but not on ~/.local/share/applications we can't tell if it's an untrusted download or a locally installed app. That might make people unhappy so I propose we have a unified method for Thunar, the Desktop and the app finder to scan through folders for installed .desktop files. A APP_PATH environment variable or Xfconf key if you will. Then advanced users and developers can easily add their custom-built apps and novice users can stick to their distro's system and enjoy Apps that run without warnings. We can also provide a UI or interaction techniques (i.e., an "apps://" view in Thunar just like "trash://") in which app bundles or existing App files can be copied, that would create the appropriate .desktop file in a valid location. Other decision criteria: For existing malware as of today since there isn't any sandboxing, they can trivially set the exec bit on files the user owns so this would do nothing to help. When a user does not have permission to run a binary but owns a file, it may be that they imported it from a trusted source on an exotic FS or downloaded it from a trusted source. In any case it's a relatively uncommon scenario: all install scripts should set exec bits on binaries and create Desktop files in appropriate locations. It makes no sense to treat desktop files specially if they have/don't have the exec bit. That's not the semantics of the exec bit in UNIX, in fact desktop files are not meant to be executable. We're on our own if we want to standardise the behaviour of those files given the number of people who create them, and it also does not cover the case of malware adding its own executables to the system. Besides the exec bit, it could be nice to say that if an App file is outside the boundaries of the adversaries considered in the threat model (i.e. "normal" existing apps, and user downloads of all kinds) then it's safe to execute it. This is impossible without sandboxing user apps and without providing users with a way to flag a downloaded file is a trustworthy app (i.e. local installations). Distributors may one day ask to let them make decisions about how Thunar should behave. This is mostly covered in the settings UI. Hardcoded decisions should be discussed on the ML and documented though so we can discuss whether it makes sense to expose alternatives to downstream and avoid downstream patching. Recommended actions: - Unify all App files under a single logical unit - By default, let App files in "installed" locations be executed without warning - By default, warn about unknown App files - Implement a "App launched" notification outside the concerned apps that watches startup notifications - Implement a "Cancel/Edit/Run" dialog and have it validated by the UX people - Implement a warning UI and have it validated by the UX people, (assigned: ???, sidi) - Provide a setting UI to allow users to choose, for installed apps and unknwo apps, whether to use "Launch", "Launch without notification", "Cancel/Edit/Run" "Warning" or "Default Edit" - Design the UI to be highly recognisable, move it into libxfce4ui and document how to use it for other Xfce packages (assigned: sidi)
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.
*** Bug 11297 has been marked as a duplicate of this bug. ***
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).
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 executions. - I would discuss a xfconf key to enable the "Edit" button in the warning, as novice users are unlikely to know how to edit a script and advanced users know how to change their settings. Ideally we need usage data to know if many users want to edit their scripts and if we're gonna piss those users off. A disabled option allows distros to adapt to their userbase, though. - Verifying compatible apps could be done with https://developer.gnome.org/gio/stable/GAppInfo.html or "xdg-mime query default" (bad, scripting) - "Don't ask in the future" types of options are usually bad. They provide immediate rewards but then users don't know how to restore behaviour, whilst gettings users into the settings in the first place teaches them where to revert the options Ping me if something's poorly justified/controversial and I'll comment below.
(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).
(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 support as much OEM customisation as we reasonably can.
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....
(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.
(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!
*** Bug 7596 has been marked as a duplicate of this bug. ***
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?
*** Bug 7554 has been marked as a duplicate of this bug. ***
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?
*** Bug 15573 has been marked as a duplicate of this bug. ***
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.
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.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/50. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev