On Wed, 2011-08-31 at 17:16 -0400, Jasper St. Pierre wrote: [...] > On Wed, Aug 31, 2011 at 4:32 PM, Owen Taylor <[email protected]> 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 _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
