(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)
--
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
