> 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, > 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. Alan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
