On Thu, Mar 15, 2012 at 3:26 AM, Chris Jones <cjo...@mozilla.com> wrote: > That's right: the ideal model is one process per "app" and one process per > <iframe browser> (arbitrary web content).
processes (fork) are not secure, and are not securable. privilege escalation is still possible. for maximum security (even when not using SE/Linux to audit, track and enforce security), exec has to be used. that means designing the system so that there is inter-process communication. and in the case under discussion, that's actually very very easy to add.... to XPCOM. COM, which inspired XPCOM, can have its parameters marshalled, shipped over an inter-process communications pipe, and unmarshalled, because the fundamental basis of COM is actually DCE/RPC. so there is absolutely no reason in the world why XPCOM should not also be properly upgraded to use DCE/RPC. there are at least two suitable implementations out there: one is http://freedce.sf.net and the other is in Wine. the license on freedce is both BSD and LGPLv2+. now, for precisely the reasons you raised chris (speed and memory requirements optimised when things like security are blatantly ignored) microsoft chose to make an "optimisation" to COM where the inter-process communication could be removed and the parameters swapped on the stack. i believe they may actually have used COM to construct the function call parameter stack in assembly code by the marshaller/unmarshaller :) so, anyway: if you've got the pieces in place, you can make the decision. but... yeah. the above is quite a bit of work. it's why i recommended the architecture of just creating JSONRPC services for all B2G back-end functionality instead. i'm actually quite concerned that to the Mozilla Foundation, with its technical hammer called "WebAPI", that all technical problems are now looking like nails. l. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
