Open Bug 1376814 Opened 3 years ago Updated 3 years ago
[Windows] Remove $PROFILE/extensions read access from level 3 content sandbox
Once XPCOM extensions are no longer supported, we should be able to remove our sandbox exclusion to allow read access to the $PROFILE/extensions directory.
We decided to defer this from 57 to 58, but I don't think we can remove this yet given bug 1393805.
Mmm, are we stuck with this forever then? Or is there a plan to someday stop using framescripst with the legacy API for system addons?
Mark, do you know if there's a time frame for when system addons won't be dependent on using legacy API frame scripts? I wouldn't say that content processes having access to $PROFILE/extensions is a pressing sandboxing issue, but something we'd like to remove as soon as there are no longer dependencies on it.
(In reply to Haik Aftandilian [:haik] from comment #3) > Mark, do you know if there's a time frame for when system addons won't be > dependent on using legacy API frame scripts? As far as I know there have been no discussions on this. Last I knew the discussion was that legacy and hybrid style add-ons would continue to be supported for system add-ons because there are always going to be things that we want to do with system add-ons that WebExtensions won't ever be able to do. I don't know enough about the background/frame script style processes in WebExtensions to know if they would cover us fully. I would suggest starting a discussion on the go-faster mailing list, and maybe firefox-dev, since they are the main places of interest for this.
I doubt we'll ever be in a position where webextensions cover all the use-cases we'd want for system add-ons. I don't think this is going to be an option.
Is the problem just that XPCOM add-ons are loading frame scripts from file: URLs? If so, they should be able to avoid causing sandboxing problems by using blob: URLs (or data: URLs) instead. (If it's a jar:file: then the easiest way is probably to XHR it as a Blob and use that; otherwise, for a plain file, the chrome-privileged File constructors are probably more efficient.)
However, we do now have now a very limited set of extensions that are legacy. So we have the ability to make changes without having blanket decisions. A firefox-dev email is probably a good place to start.
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #6) > Is the problem just that XPCOM add-ons are loading frame scripts from file: > URLs? If so, they should be able to avoid causing sandboxing problems by > using blob: URLs (or data: URLs) instead. The current add-ons use either chrome:// or resource:// uris. Possibly useful link: http://searchfox.org/mozilla-central/search?q=loadFrameScript&case=false®exp=false&path=browser%2Fextensions
My understanding is that chrome:// and resource:// are basically fancy URL shorteners — when they're used they expand into another URL (usually jar:file: or file:) and that's loaded normally. (nsIChromeRegistry::ConvertChromeURL and nsISubstitutingProtocolHandler::GetSubstitution seem to be the methods to do the rewriting separately.) From the OS's point of view there's no difference between that and using a file: URL directly. And the same workaround should work: XHR to get the data as a Blob and createObjectURL to get a URL for loadFrameScript.
I wrote out the logic I had in mind for converting URLs… and discovered that it doesn't work because of a bug in loadFrameScript, which I've filed (bug 1412114). In practice this should have some memoization so it doesn't wind up allocating multiple blobs for the same script, and maybe some way to revoke the blob URLs when no longer needed (but that might be counterproductive if the message manager is going to cache the script forever, as some code comments indicate).
You need to log in before you can comment on or make changes to this bug.