[Bug 1327791] Re: Security warning about just created Xubuntu desktop shortcut
** Changed in: thunar (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
*** Bug 15573 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
*** Bug 7554 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
*** Bug 7596 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
(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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1327791
Title:
Security warning about just created Xubuntu desktop shortcut
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
(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). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
(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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
(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! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
*** Bug 11297 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791] Re: Security warning about just created Xubuntu desktop shortcut
** Bug watch added: Xfce Bugzilla #11297 https://bugzilla.xfce.org/show_bug.cgi?id=11297 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791]
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) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791] Re: Security warning about just created Xubuntu desktop shortcut
** Package changed: xfdesktop4 (Ubuntu) = thunar (Ubuntu) ** Bug watch added: Xfce Bugzilla #9934 https://bugzilla.xfce.org/show_bug.cgi?id=9934 ** Also affects: thunar via https://bugzilla.xfce.org/show_bug.cgi?id=9934 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1327791] Re: Security warning about just created Xubuntu desktop shortcut
Launchpad has imported 7 comments from the remote bug at https://bugzilla.xfce.org/show_bug.cgi?id=9934. If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. On 2013-03-18T12:32:18+00:00 Guido Berhoerster wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1327791/comments/0 On 2014-07-20T14:13:54+00:00 Eric Koegel wrote: *** Bug 10273 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1327791/comments/2 On 2014-07-26T22:56:30+00:00 Michael Orlitzky wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1327791/comments/3 On 2014-08-05T08:35:07+00:00 Yves-Alexis Perez wrote: See also bug #7554 Reply at: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1327791/comments/4 On 2014-08-05T09:36:09+00:00 Guido Berhoerster wrote: (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). Reply at: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1327791/comments/5 On 2014-08-05T09:38:56+00:00 Yves-Alexis Perez wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1327791/comments/6 On 2014-08-05T09:44:54+00:00 Guido Berhoerster wrote: (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
[Bug 1327791] [NEW] Security warning about just created Xubuntu desktop shortcut
Public bug reported: 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 ** Affects: xfdesktop4 (Ubuntu) Importance: Undecided Status: New ** Package changed: parole (Ubuntu) = xfdesktop4 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327791 Title: Security warning about just created Xubuntu desktop shortcut To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1327791/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
