Hey Henri, Freddy pointed me to the sandboxing part of the question, here is my impression.
In general, if the Sandbox is running any additional code that is not in the tree could also be accomplished with a compromised child process. However in case of dlopen() it is important to know our Sandbox is not immediately active upon process start, rather it is an ipc message that is received on the child side to activate sandboxing. So if the dlopen happens before the Sandbox ipc message is received the loaded code can do dangerous stuff (e.g. By declaring a ctor constructor function of the library that is executed upon loading) Second, if the dl is injected into the parent it can possibly expose a new way for the child to communicate with the parent which would expose more attack surface. And of course the code injected into the child can be vulnerable and expose more attack surface for the child which could make it easier to be compromised. I hope that answers your question. Julian On Mar 22, 2017 16:09, "Henri Sivonen" <hsivo...@hsivonen.fi> wrote: > On Wed, Mar 22, 2017 at 4:45 PM, Axel Hecht <l...@mozilla.com> wrote: > > Am 22.03.17 um 15:39 schrieb Jorge Villalobos: > >> > >> On 3/22/17 8:10 AM, Henri Sivonen wrote: > >>> > >>> On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron > >>> <nicolas.b.pier...@mozilla.com> wrote: > >>>> > >>>> On 03/22/2017 09:18 AM, Henri Sivonen wrote: > >>>>> > >>>>> > >>>>> Without XPCOM extensions, what's the story for out-of-tree spell > >>>>> checkers? > >>>>> > >>>>> […], which implements > >>>>> mozISpellCheckingEngine in JS and connects to the libvoikko[1] back > >>>>> end via jsctypes. […] > >>>> > >>>> > >>>> > >>>> Would compiling libvoikko to WebAssembly remove the need for jsctypes > >>>> and > >>>> XPCOM? > >>> > >>> > >>> It would remove the need for jsctypes, but how would a WebAssembly > >>> program in a Web Extension get to act as a spell checking engine once > >>> extensions can no longer implement XPCOM interfaces > >>> (mozISpellCheckingEngine in this case)? > >>> > >> > >> Note there is a bug on file to implement an spell-checker API for > >> WebExtensions: https://bugzilla.mozilla.org/show_bug.cgi?id=1343551 > >> > >> The API request was approved but is low priority. > >> > >> Jorge > >> > > > > Note, that bug seems about using an API like mozISpellCheckingEngine from > > web extensions. > > > > It doesn't seem to be about providing an implementation of it via a web > > extension. > > Indeed. > > Considering that there seems to be only one out-of-tree library that > gets glued into a mozISpellCheckingEngine provider (libvoikko), it > seems to me that it would be misplaced effort if Mozilla designed a > Web Extension API for providing a spell checker and then asked the > Voikko developers to figure out how to compile the code into > WebAssembly and how to package the wasm and all the data files as a > Web Extension. > > dlopening libvoikko, if installed, and having thin C++ glue code > in-tree seems much simpler, except maybe for sandboxing. What are the > sandboxing implications of dlopening a shared library that will want > to load its data files? > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
