Daniel Benamy wrote: > multiple programs without them messing each other up. An important > mechanism to enable this is separate address spaces for each process. > But our apps in different tabs all run in the same address space (as > far as I know) so if one app exploits a vulnerability or triggers a > bug in the js interpreter or an image parser or something they may > have access to something important like our banking information which > is being displayed in another tab. So I was curious about how > difficult it would be to modify the browser so that there's a main > process which does network stuff and ui stuff and manages the cache > and most of the general web browser functionality, but it doesn't try > to understand anything sent down by a web server. Instead it passes > that data to a separate process which is responsible for actually > rendering the content of the page and passes the finished static > product back. So the understanding/rendering process would have the > isolation provided by the OS and any problems couldn't spill over to > other tabs. Additionally, the understanding and rendering process > could be highly sandboxed using selinux or apparmor or whatever other > security tools people like. Since it's output would be through such a > restricted channel and in such a (hopefully) safe way, I'd think it > could be set up so that even if it's exploited to allow arbitrary code > execution, the attacker couldn't harm any local resources like the > filesystem.
Yes, we have considered this... it is in fact very hard to do correctly. The major problem is that windows may communicate with eachother via JavaScript. One window can obtain a reference to another window via window.open(). And website JavaScript has a run-to-completion semantic which means that it doesn't expect other JS to modify its state while a script is running; this means that naive locking schemes which only protect against inconsistent data are not sufficient. In Mozilla2 we are working towards a unified memory model (garbage collector) for JS objects and DOM (XPCOM) objects. After this work is complete we can seriously consider whether it is possible to distribute this GC over multiple processes as well as provide correct behavior to JS. --BDS _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
