Re: Notes on extensions.gnome.org security

[Owen Taylor <otaylor redhat com>]

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

So I think it would be hard to make a truly bulletproof system - Java
was designed for this from the start and there are still problems
popping up.

The one thing you might be able to achieve this way would be to make
ill-intentioned extensions more obvious in code review; it might be
worth exploring in this direction, but I don't see it as being an
alternative to review of extension code.

> >  - 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.
> 
> I'm unsure about this -- I don't think that an update or blacklist
> mechanism should touch anything that the user or a system
> administrator installed themselves.
> 
> Of course, if we try to record which extensions got installed through
> the website, even with just a simple

I like the simplicity of saying "I have alternative-alt-tab 0.4 is
there an update?", rather than having the possibility that you might
have that extension installed, but from a different location, or with
something funny in its metadata file. That would only apply to
extensions installed in the user's directory, not systemwide,
presumably.

I don't feel strongly here, but I'd certainly vote in favor of
simplicity and centralization.

[..]

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

A hard requirement for me is that a HTML-injection problem on
extensions.gnome.org can't make the plugin download and install random
code from a random site. The two ways I can think of to address this
are:

 A) Make the plugin only tell the downloader what to download and not
    to download it from.
 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.)

- Owen