Re: Notes on extensions.gnome.org security

[Wouter De Borger <w deborger gmail com>]

I think sandboxing is not the only option, 
Spidermonkey supports stack walking, so it would be possible to assign a set of permissions to each extension and enforce them at run-time.
The same principle is used in Java, to allow applets to selectively access priviledged resources. 

It would of course take quite some work to maintain the permission sets (as is the case for SELinux). On the other hand, it would make the reviewers life a lot easier, as they can just read through the permission set and see if it contains anything bad/odd. If the extension would change its behavior once deployed, the stack traceing mechanism would block all bad/unexpected things.

It would also take quite some work to design a good permission model: if you make it too fine grained, the permission sets become huge, if you make it too coarse, it is useless.
But if security is really an issue, now is the time to implement it. 

On the other hand, I trust the crowd, if things go bad, someone will fix it, if not, I have the extensions source, so I can probably fix it myself,...

Wouter

On Wed, Aug 31, 2011 at 22:32, Owen Taylor <otaylor redhat com> wrote:

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.


_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list