Notes on extensions.gnome.org security

[Owen Taylor <otaylor redhat com>]

The idea of a GNOME Shell extension is to let the GNOME community
build on top of the GNOME Shell code base, to tweak, to customize, and
to prototype new GNOME features and behaviors.

GNOME Shell extensions aren't sandboxed, and sandboxing them is
fundamentally hard because shell extensions are defined as arbitrary
tweaks to GNOME Shell. GNOME Shell is in the position to do such
things as add global keybindings or read screen content, thus shell
have the same capabilities.

Of course, Linux users run unsandboxed code with arbitary capabilities
every day - applications, for example. So the security question with
GNOME Shell extensions is not how we can do the almost impossible job
of sandboxing them, but how we can build up layers of social, user
interface, and technical protections to make them not an attractive
deployment mechanism for malware.

For an average user, one of the most important thing that we can do is
to make sure that it is actively hard to install extensions from
untrusted sources. It shouldn't be possible to simply click on a web
page link which downloads an extensions and then be prompted to
install it. It's been well demonstrated that no form of confirmation
dialog or warning text provides effective protection in such cases.

By instead directing the user to extensions on extensions.gnome.org we
achieve multiple things: we can have a review process for extensions,
rankings and reviews will direct the user to heavily tested extensions
and away from misbehaving extensions, we will make sure that we can
update extensions, and even remove them if security problems pop up.

The "sweettooth plugin"
========================

In general, having the interface to find and install extensions be a
website is attractive: it is a very natural way to include social
aspects like ratings and recommendations into the interface and allows
the information/installation page for an extension to be directly
linked to from an external web page.

However, as noted above, simple approaches for installing extensions
like a MIME-type handler can be dangerous since they could be used
to provide a code download from an arbitrary location.

The current approach taken is to provide a browser plugin that
enforces an origin from extensions.gnome.org and provides the
following methods to the website:

  listExtensions()
  getExtensionInfo()
  installExtension()
  setExtensionEnabled()
  getExtensionErrors()

This allows embedding an interface for mananging extensions directly
into the website.

Threat model and mitigation
===========================

The basic danger that we want to avoid is that someone gets an
extension installed onto their system that has malicious code in it.

The most basic way that this would happen is that someone simply
uploads an extension to the website that is malicious, and that it
gets through the review process without anybody noticing.

Mitigation:

 - Require code review for all updates of an extension not just the
   initial upload.
 - Provide clear code review guidelines, including that an
   extension with hard to understand or tricky code should be
   rejected.
 - Provide tools to let a reviewer see what has changed in an update
   of an extension to let them focus more attention on the changed
   part.
 - Use identity in the review process, so, e.g., it's very clear
   when an update to an extension is uploaded by someone other than
   the original author.
 - Make it very difficult to install an unreviewed extension; it
   should not be easy for a reviewer to try out an extension to
   "see what it does" before they look at the code. It should not
   be possible for a user to install an unreviewed extension from
   the website simply by confirming a warning dialog.

Another possibility would be a system-level exploit of
extensions.gnome.org allowing modification of the code or uploaded
extensions. Other the general security measures we take for all
gnome.org servers, there are not a lot of things we can do about
this, a few ideas:

 - Make sure that it's explicit to the user when updates to
   extensions or new extensions are being installed. This doesn't
   do much to directly protect the vast majority of users, but
   should allow quick detection of "funny business" by the community
   in general.

 - Add some capability for "self-healing" to the extension update
   mechanism. There's not much we can do if an extension once run
   installs a back-door on the user's system, but we should be able
   to remove known bad extensions through the update process, even
   if the extension doesn't have proper update metadata.

Somewhat similarly, there is a danger if a user with commit access to
gnome.org introduces code into the extensions.gnome.org website that
then gets deployed on the server. Obviously, this is something we also
need to deal with for commits to general GNOME code, but the ability
to immediately get things installed on user's systems makes the window
to detect problems shorter for extensions.gnome.org.

Possible measures:

 - Don't have automatic deployment for extensions.gnome.org changes
   but make it a manual process.
 - Restrict the set of users who can commit to the
   extensions.gnome.org code module.

Beyond this, the use of a browser plugin could provide the following
dangers:

 * There might be a direct hole in the browser plugin code that
   allows arbitrary code execution.

   Mitigation:

   - careful code review of the plugin.
   - check the originating web page very early in the process
     and don't allow untrusted web sites to even call most
     of the code in the plugin.

 * By cross-site scripting techniques someone could manage to figure
   out how to trigger installation without an explicit request
   from the user. Similarly, a bug in the origin checking logic
   might allow the plugin to be embedded and controlled by a
   website other than extensions.gnome.org.

   Mitigation:

    - make gnome-shell show a dialog before installing an extension.
    - make it impossible to install an unreviewed extension through
      the mechanism that the plugin uses
    - make it impossible to install an extension from somewhere other
      than extensions.gnome.org via the mechanism that the plugin
      uses.

   If all that the plugin can do is say "install plugin GUID x-y-z",
   whch that then triggers a download from https://extensions.gnome.org
   and shows a dialog, then any exploits along this line should at
   least be detectable to moderately sophisticated users, who will
   hopefully then report them so they can be fixed.

"Websites are websites, configuration is configuration!" ?
==========================================================

Colin Walters expressed a strong opinion to me that he was
uncomfortable with the idea of having a GUI to install and enable
extensions be embedded into a website. That controls on websites
should not effect the local state of the computer, period.

He said that even if the extensions installation application was
implemented as a web page, he'd be much more comfortable if it was run
only as an embedded web page within a dedicated application rather
than in a general-purpose web page.

While I can sympathize with this, it's a view that is accomodating the
the mental model of sophisticated users who are able to figure things
out in any case. For a less sophisticated user the important thing is
making things as clear and simple as possible, to let them focus on
what they are doing, rather than how. I think the website approach
works well for this.

(Another factor here is that we want a clear separation where
extensions are something you have to go out of your way to find;
turning on extensions is a completely different form of customization
than, say, changing your time zone. So, we'd have to do something like
make the extensions application only accessible through the Alt-F2
run dialog.)

"Extensions should be packaged!" ?
==================================

If we just treated extensions like all other code on a linux
distribution and didn't have extensions.gnome.org, then we wouldn't
introduce new security risks.

However, this does not correspond to our overall goals for extensions:
we want a very clear distinction between extensions and applications,
we want extension installation to be under the control of the user
and not the system builder, and we want to encourage a community of
extension creation that doesn't involve an extra layer of distribution
specific packaging.

Conclusion
==========

A model where we encourage users to download and run code that doesn't
go through the normal GNOME channels of patch review, release and
packaging clearly presents new security challenges. The most important
thing we can do to address these challenges is to make sure that we
have a review process and solid update mechanism in place. This is
achieved by making extensions.gnome.org the central location
for extensions.

Beyond this, the security challenges posed by extensions.gnome.org are
mostly standard ones of maintaining website and code security. Certain
mitigation measures indentified above: in particular making the
interfaces used by the plugin limited to installing extensions from
extensions.gnome.org and providing explicit client-side notification
during installation and update of extensions can provide an extra
layer of security.