Re: Notes on extensions.gnome.org security

[Owen Taylor <otaylor redhat com>]

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.

 - An adminstrator takes the signed extensions, checks the reviewers
   signature and then adds the official GNOME signature.

That would be very secure, but it also creates manual steps and points
of failure that would likely make the system just not work in practice.

We shouldn't forget either that our opinion about whether an extension
is safe can change over time. A signature only means that that exact
code base passed review at one point in time. But we later could
discover problems with it. Another reason I tend to like centralization
rather than only relying on embedded signatures.

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

In terms of these security goals, I think the mime type system could be
adapted - that is, we could define a mime type
text/x-gnome-shell-extensions-install-manifest, and when you clicked on
it, the right things happen.

The plugin mostly is about improving the UI beyond that - being able to
mark extensions you alread have installed, be able to disable them from
the web, etc.

> > 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.
> 
> In which case you probably do also want a system wide ability to turn off
> users adding extensons, especially unsigned ones, for business
> environments.

It should be already possible to lock down the enabled-extensions
gsettings, so the main thing would be adapting the UI to make it clear
to the user that it was the case.

- Owen