Owen Taylor | 31 Aug 22:32 2011
Picon

Notes on extensions.gnome.org security

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.

(Continue reading)

Jasper St. Pierre | 31 Aug 23:16 2011
Picon

Re: Notes on extensions.gnome.org security

(Just a few comments on what's currently implemented)

Obviously, this website and its goals have some parallels with the
Mozila Addons site. I have been talking to their engineers and we both
decided that doing our own thing would be best for both of us. I have
been talking to them about how "AMO" works internally: I have some
similar engineering decisions here, and precedent is always nice.

On Wed, Aug 31, 2011 at 4:32 PM, Owen Taylor <otaylor@...> 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.

I think that there should at least be some attempt to try and do
limited, but important sandboxing like "you cannot write to any files
except in storage that the extension system has allocated for you",
"you are not allowed to spawn any applications", "you are not allowed
to open any sockets" or "you are not allowed to make gsettings tweaks
except out of the schemas that I give you". Unfortunately, I doubt
this is possible with the current state of gjs/gobject-introspection,
but I think it's worth investigating.

> Of course, Linux users run unsandboxed code with arbitary capabilities
> every day - applications, for example. So the security question with
(Continue reading)

Stef Walter | 1 Sep 07:34 2011
Picon

Re: Notes on extensions.gnome.org security

On 08/31/2011 11:16 PM, Jasper St. Pierre wrote:
> Right now you pass the plugin an URL to a "manifest file", so it's not
> hardcoded to seek out the URL based on extensions.gnome.org. The idea
> here was that if we needed to offload the servers with the extension
> data to a CDN, we wouldn't have to make the users upgrade their
> distributions.

It seems to me either you have to:

  a) limit extensions from downloading from a known encrypted source
     (extensions.gnome.org). This precludes putting parts of the
     extension on other locations like a CDN.

  b) cryptographically sign the extensions (and all data), this allows
     you to place the extension and its parts on CDNs.

As Alan brought up, option b with keys not directly located on 
extensions.gnome.org also has a good security story when it comes to 
hacks on the web server.

Cheers,

Stef
Owen Taylor | 1 Sep 19:36 2011
Picon

Re: Notes on extensions.gnome.org security

On Wed, 2011-08-31 at 17:16 -0400, Jasper St. Pierre wrote:
[...]
> On Wed, Aug 31, 2011 at 4:32 PM, Owen Taylor <otaylor@...> 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.
> 
> I think that there should at least be some attempt to try and do
> limited, but important sandboxing like "you cannot write to any files
> except in storage that the extension system has allocated for you",
> "you are not allowed to spawn any applications", "you are not allowed
> to open any sockets" or "you are not allowed to make gsettings tweaks
> except out of the schemas that I give you". Unfortunately, I doubt
> this is possible with the current state of gjs/gobject-introspection,
> but I think it's worth investigating.

I'm not all that optimistic about this - on one hand, extensions do need
to be able to do "dangerous" things - I'd consider an extension that
modified or replaced the onscreen keyboard legitimate - and once you can
act as the onscreen keyboard, you can type arbitrary stuff into a
terminal. And on the other hand, the GNOME API's aren't designed to be
protected against users with bad intent. E.g., in GTK+ if you change the
widget hierarchy out of a ::paint signal, you'll crash GTK+.

(Continue reading)

Alan Cox | 1 Sep 19:56 2011
Face
Picon

Re: Notes on extensions.gnome.org security

>  A) Make the plugin only tell the downloader what to download and not
>     to download it from.

You still need a key - even if the https:// authentication for gnome.org
itself to prove the connection is to the correct site.

>  B) Sign extension dowloads with a gnome.org private key.
> 
> A) is considerably simpler. B) offers some more flexibility. (You can
> still handle offload in the A) case by doing redirects.)

Another way to address B is to sign an index of locations of and hashes
for the extensions rather than signing each extension individually. Might
be easier to operate but with B you could use a heirarchy of keys
(gnome->signer) which would let the installer see who (one or many) signed
the package having reviewed it, and also allow revocations.

Alan Cox | 31 Aug 23:35 2011
Face
Picon

Re: Notes on extensions.gnome.org security

> 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.

I would say the question is both that and how you sandbox them to some
extent in the same way as you sandbox apps with SELinux. That requires
sensible architecture decisions about isolation. An extension that wants
to look at my ssh keys for example is detectable as anomalous behaviour.

>  - 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.

- Sign 'approved' extensions with keys which are not kept on a public
  system.

>    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.

Are the existing mime type and helpers not sufficient ?

> However, this does not correspond to our overall goals for extensions:
> we want a very clear distinction between extensions and applications,
(Continue reading)

Owen Taylor | 1 Sep 20:22 2011
Picon

Re: Notes on extensions.gnome.org security

On Wed, 2011-08-31 at 22:35 +0100, Alan Cox wrote:
> > 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.
> 
> I would say the question is both that and how you sandbox them to some
> extent in the same way as you sandbox apps with SELinux. That requires
> sensible architecture decisions about isolation. An extension that wants
> to look at my ssh keys for example is detectable as anomalous behaviour.

> >  - 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.
> 
> - Sign 'approved' extensions with keys which are not kept on a public
>   system.

Yes. In theory signatures can offer a layer of security that is
independent of the security of the hosting of extensions. It's hard for
me to wrap my head around a way to make that practical, if we want to be
able to review and approve extensions through the web UI.

Schemes I can come up end up with end up with something like:

 - Reviewers download and review extensions locally, then sign them
   with their GPG key.
(Continue reading)

Wouter De Borger | 1 Sep 11:49 2011
Picon

Re: Notes on extensions.gnome.org security

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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-rDKQcyrBJuzYtjvyW6yDsg@public.gmane.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

<div>
<p>I think <a href="https://developer.mozilla.org/En/SpiderMonkey/JSAPI_User_Guide#Object-capabilities-based_security">sandboxing</a> is not the only option, <br>Spidermonkey supports <a href="https://developer.mozilla.org/En/SpiderMonkey/JSAPI_User_Guide#Fine-grained_security">stack walking</a>, so it would be possible to assign a set of permissions to each extension and enforce them at run-time.<br>
The same principle is used in <a href="http://www.cs.princeton.edu/sip/pub/oakland98.pdf">Java</a>, to allow applets to selectively access priviledged resources. <br><br>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.<br><br>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.<br>But if security is really an issue, now is the time to implement it. <br><br>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,...<br><br>Wouter<br><br></p>
<div class="gmail_quote">On Wed, Aug 31, 2011 at 22:32, Owen Taylor <span dir="ltr">&lt;<a href="mailto:otaylor <at> redhat.com">otaylor@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">The idea of a GNOME Shell extension is to let the GNOME community<br>
build on top of the GNOME Shell code base, to tweak, to customize, and<br>
to prototype new GNOME features and behaviors.<br><br>
GNOME Shell extensions aren't sandboxed, and sandboxing them is<br>
fundamentally hard because shell extensions are defined as arbitrary<br>
tweaks to GNOME Shell. GNOME Shell is in the position to do such<br>
things as add global keybindings or read screen content, thus shell<br>
have the same capabilities.<br><br>
Of course, Linux users run unsandboxed code with arbitary capabilities<br>
every day - applications, for example. So the security question with<br>
GNOME Shell extensions is not how we can do the almost impossible job<br>
of sandboxing them, but how we can build up layers of social, user<br>
interface, and technical protections to make them not an attractive<br>
deployment mechanism for malware.<br><br>
For an average user, one of the most important thing that we can do is<br>
to make sure that it is actively hard to install extensions from<br>
untrusted sources. It shouldn't be possible to simply click on a web<br>
page link which downloads an extensions and then be prompted to<br>
install it. It's been well demonstrated that no form of confirmation<br>
dialog or warning text provides effective protection in such cases.<br><br>
By instead directing the user to extensions on <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> we<br>
achieve multiple things: we can have a review process for extensions,<br>
rankings and reviews will direct the user to heavily tested extensions<br>
and away from misbehaving extensions, we will make sure that we can<br>
update extensions, and even remove them if security problems pop up.<br><br>
The "sweettooth plugin"<br>
========================<br><br>
In general, having the interface to find and install extensions be a<br>
website is attractive: it is a very natural way to include social<br>
aspects like ratings and recommendations into the interface and allows<br>
the information/installation page for an extension to be directly<br>
linked to from an external web page.<br><br>
However, as noted above, simple approaches for installing extensions<br>
like a MIME-type handler can be dangerous since they could be used<br>
to provide a code download from an arbitrary location.<br><br>
The current approach taken is to provide a browser plugin that<br>
enforces an origin from <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> and provides the<br>
following methods to the website:<br><br>
 &nbsp;listExtensions()<br>
 &nbsp;getExtensionInfo()<br>
 &nbsp;installExtension()<br>
 &nbsp;setExtensionEnabled()<br>
 &nbsp;getExtensionErrors()<br><br>
This allows embedding an interface for mananging extensions directly<br>
into the website.<br><br>
Threat model and mitigation<br>
===========================<br><br>
The basic danger that we want to avoid is that someone gets an<br>
extension installed onto their system that has malicious code in it.<br><br>
The most basic way that this would happen is that someone simply<br>
uploads an extension to the website that is malicious, and that it<br>
gets through the review process without anybody noticing.<br><br>
Mitigation:<br><br>
&nbsp;- Require code review for all updates of an extension not just the<br>
 &nbsp; initial upload.<br>
&nbsp;- Provide clear code review guidelines, including that an<br>
 &nbsp; extension with hard to understand or tricky code should be<br>
 &nbsp; rejected.<br>
&nbsp;- Provide tools to let a reviewer see what has changed in an update<br>
 &nbsp; of an extension to let them focus more attention on the changed<br>
 &nbsp; part.<br>
&nbsp;- Use identity in the review process, so, e.g., it's very clear<br>
 &nbsp; when an update to an extension is uploaded by someone other than<br>
 &nbsp; the original author.<br>
&nbsp;- Make it very difficult to install an unreviewed extension; it<br>
 &nbsp; should not be easy for a reviewer to try out an extension to<br>
 &nbsp; "see what it does" before they look at the code. It should not<br>
 &nbsp; be possible for a user to install an unreviewed extension from<br>
 &nbsp; the website simply by confirming a warning dialog.<br><br>
Another possibility would be a system-level exploit of<br><a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> allowing modification of the code or uploaded<br>
extensions. Other the general security measures we take for all<br><a href="http://gnome.org" target="_blank">gnome.org</a> servers, there are not a lot of things we can do about<br>
this, a few ideas:<br><br>
&nbsp;- Make sure that it's explicit to the user when updates to<br>
 &nbsp; extensions or new extensions are being installed. This doesn't<br>
 &nbsp; do much to directly protect the vast majority of users, but<br>
 &nbsp; should allow quick detection of "funny business" by the community<br>
 &nbsp; in general.<br><br>
&nbsp;- Add some capability for "self-healing" to the extension update<br>
 &nbsp; mechanism. There's not much we can do if an extension once run<br>
 &nbsp; installs a back-door on the user's system, but we should be able<br>
 &nbsp; to remove known bad extensions through the update process, even<br>
 &nbsp; if the extension doesn't have proper update metadata.<br><br>
Somewhat similarly, there is a danger if a user with commit access to<br><a href="http://gnome.org" target="_blank">gnome.org</a> introduces code into the <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> website that<br>
then gets deployed on the server. Obviously, this is something we also<br>
need to deal with for commits to general GNOME code, but the ability<br>
to immediately get things installed on user's systems makes the window<br>
to detect problems shorter for <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a>.<br><br>
Possible measures:<br><br>
&nbsp;- Don't have automatic deployment for <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> changes<br>
 &nbsp; but make it a manual process.<br>
&nbsp;- Restrict the set of users who can commit to the<br>
 &nbsp; <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> code module.<br><br>
Beyond this, the use of a browser plugin could provide the following<br>
dangers:<br><br>
&nbsp;* There might be a direct hole in the browser plugin code that<br>
 &nbsp; allows arbitrary code execution.<br><br>
 &nbsp; Mitigation:<br><br>
 &nbsp; - careful code review of the plugin.<br>
 &nbsp; - check the originating web page very early in the process<br>
 &nbsp; &nbsp; and don't allow untrusted web sites to even call most<br>
 &nbsp; &nbsp; of the code in the plugin.<br><br>
&nbsp;* By cross-site scripting techniques someone could manage to figure<br>
 &nbsp; out how to trigger installation without an explicit request<br>
 &nbsp; from the user. Similarly, a bug in the origin checking logic<br>
 &nbsp; might allow the plugin to be embedded and controlled by a<br>
 &nbsp; website other than <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a>.<br><br>
 &nbsp; Mitigation:<br><br>
 &nbsp; &nbsp;- make gnome-shell show a dialog before installing an extension.<br>
 &nbsp; &nbsp;- make it impossible to install an unreviewed extension through<br>
 &nbsp; &nbsp; &nbsp;the mechanism that the plugin uses<br>
 &nbsp; &nbsp;- make it impossible to install an extension from somewhere other<br>
 &nbsp; &nbsp; &nbsp;than <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> via the mechanism that the plugin<br>
 &nbsp; &nbsp; &nbsp;uses.<br><br>
 &nbsp; If all that the plugin can do is say "install plugin GUID x-y-z",<br>
 &nbsp; whch that then triggers a download from <a href="https://extensions.gnome.org" target="_blank">https://extensions.gnome.org</a><br>
 &nbsp; and shows a dialog, then any exploits along this line should at<br>
 &nbsp; least be detectable to moderately sophisticated users, who will<br>
 &nbsp; hopefully then report them so they can be fixed.<br><br>
"Websites are websites, configuration is configuration!" ?<br>
==========================================================<br><br>
Colin Walters expressed a strong opinion to me that he was<br>
uncomfortable with the idea of having a GUI to install and enable<br>
extensions be embedded into a website. That controls on websites<br>
should not effect the local state of the computer, period.<br><br>
He said that even if the extensions installation application was<br>
implemented as a web page, he'd be much more comfortable if it was run<br>
only as an embedded web page within a dedicated application rather<br>
than in a general-purpose web page.<br><br>
While I can sympathize with this, it's a view that is accomodating the<br>
the mental model of sophisticated users who are able to figure things<br>
out in any case. For a less sophisticated user the important thing is<br>
making things as clear and simple as possible, to let them focus on<br>
what they are doing, rather than how. I think the website approach<br>
works well for this.<br><br>
(Another factor here is that we want a clear separation where<br>
extensions are something you have to go out of your way to find;<br>
turning on extensions is a completely different form of customization<br>
than, say, changing your time zone. So, we'd have to do something like<br>
make the extensions application only accessible through the Alt-F2<br>
run dialog.)<br><br>
"Extensions should be packaged!" ?<br>
==================================<br><br>
If we just treated extensions like all other code on a linux<br>
distribution and didn't have <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a>, then we wouldn't<br>
introduce new security risks.<br><br>
However, this does not correspond to our overall goals for extensions:<br>
we want a very clear distinction between extensions and applications,<br>
we want extension installation to be under the control of the user<br>
and not the system builder, and we want to encourage a community of<br>
extension creation that doesn't involve an extra layer of distribution<br>
specific packaging.<br><br>
Conclusion<br>
==========<br><br>
A model where we encourage users to download and run code that doesn't<br>
go through the normal GNOME channels of patch review, release and<br>
packaging clearly presents new security challenges. The most important<br>
thing we can do to address these challenges is to make sure that we<br>
have a review process and solid update mechanism in place. This is<br>
achieved by making <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> the central location<br>
for extensions.<br><br>
Beyond this, the security challenges posed by <a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> are<br>
mostly standard ones of maintaining website and code security. Certain<br>
mitigation measures indentified above: in particular making the<br>
interfaces used by the plugin limited to installing extensions from<br><a href="http://extensions.gnome.org" target="_blank">extensions.gnome.org</a> and providing explicit client-side notification<br>
during installation and update of extensions can provide an extra<br>
layer of security.<br><br><br>
_______________________________________________<br>
gnome-shell-list mailing list<br><a href="mailto:gnome-shell-list@...">gnome-shell-list@...</a><br><a href="http://mail.gnome.org/mailman/listinfo/gnome-shell-list" target="_blank">http://mail.gnome.org/mailman/listinfo/gnome-shell-list</a><br>
</blockquote>
</div>
<br>
</div>

Gmane