Hi Simon, ----- Original Message ----- From: "Simon Bennetts" <[email protected]> To: "Ian Melven" <[email protected]> Cc: [email protected] Sent: Thursday, July 26, 2012 1:43:04 AM Subject: Re: a sandboxed Firefox
> Do you know how other people have solved this with Firefox? i don't think this problem has been solved to the extent we would like it to be solved, to be honest. Previously in this thread, Kevin Chadwick made me aware of sandfox which solves one of the threats (filesystem access) on Linux. I suppose it also somewhat mitigates the threat of launching external processes to the degree that things that Firefox needs to run are accessible from the chroot jail. Plugins and addons will be a problem here, and additionally we'd need to implement a broker ourselves if we went down this approach (unless the user is fine always saving files, for example, within the jail). > I've used 'packaged' sandboxed browsers before (I think theyre a really good > idea) - cant remember which ones but a quick google came up with > http://spoon.net/browsers/ (which I've > not yet used, but also looks like a > really neat way of testing old browser versions!). > Just done a bit more googling and found this explanation of spoon.net: > http://en.wikipedia.org/wiki/Spoon_%28software%29 virtualization has been raised as an idea before - see https://bugzilla.mozilla.org/show_bug.cgi?id=730956#c1 It's certainly a valid approach to solve the threats we're concerned about, IMO. The immediate issues I can think of are the complexity of the implementation and performance degradation. Approaches along these lines for Servo have been brought up on the dev-servo list as possible areas of research as well, like control flow integrity, for example. > * Can we fake filesystem / registry access so addons that access those > wont crash (but might not work as expected)? On Windows, the chromium sandbox uses a token with almost no privileges/access, so crashing is actually an overstatement. What will happen is that when the sandboxed process calls CreateFile/CreateProcess/RegCreateKeyEx etc. it will get ERROR_ACCESS_DENIED - how it handles this failure is up to the addon. Obviously, in many cases this will reduce or completely remove the functionality of the addon. When the addon uses XPCOM interfaces, we have the opportunity to handle the filesystem/registry access in our code, which means we can potentially call a broker API or possibly dynamically whitelist and allow the call. Jesse Ruderman raised some good questions about how long access would be whitelisted for and some of the potential pitfalls with this approach, it's clearly something that would need a lot of review. > * Would it be possible to have sandboxing as a profile option, so when you > create a new profile you can select if it should be sandboxed? doing this or making it a pref or a command line option or even a compile time option so there are sandboxed builds of Firefox are all options. Doing it per profile is an interesting variant of this, IMO. The major constraint around this is that switching from sandboxed or non-sandboxed requires a browser (really, a process) restart. > * Can we detect which addons use 'unsafe' features and disable them in > sandboxed mode? the difficulty i see here is detecting at runtime when sandbox violations are caused by an addon vs by malicious code (even worse, malicious code executing the addon code via ROP or some other such technique). we can detect some level of filesystem etc via static analysis for addons on AMO for example, but this technique has its technical limitations as well. Marshall Moutenot has been looking at the top 100 addons to give us a better idea of the situation. the UX around this is.. difficult. i don't think anyone wants to be prompted every time a violation happens. > * If not we could disable all addons in sandboxed mode. yeah, this is definitely an option, although i feel like we should try to have as many users sandboxed as possible - hence we should really try and avoid this. I definitely feel like it's great for testing and shaking out compatibility issues to ship an opt-in version of sandboxing, much like we have done for click-to-play (although in the near future, we hope to have outdated/vulnerable plugins be automatically made click-to-play). > * And going one step further I think we should have finer grain controls > for addons (eg like Android apps). Could this be one step along the way? In > other words addons need to > say if they will run in the sandbox (even better if we can check that) > otherwise they will be disabled, which will be the default. there is certainly a camp that shares this opinion, see https://bugzilla.mozilla.org/show_bug.cgi?id=686134 "Addons can run arbitrary code and cause security bugs". In general, I feel that add-ons have been encouraged to move to Jetpack, or in general, to avoid binary components and use js-ctypes etc. instead to avoid compatibility issues, particularly with our current rapid release schedule. Another way to look at the situation though is that Firefox add-ons being able to do whatever they want and have full privilege enables extremely advanced add-ons that are a big differentiator with respect to other browsers with more limited, restricted API's. I believe both of these are valid points of view. thanks, ian On 26/07/2012 00:12, Ian Melven wrote: Hi, Marshall Moutenot and myself have been researching the idea of sandboxing the Firefox.exe process, starting on Windows. some of the issues and risks and our current plan can be found on the freshly updated feature page at https://wiki.mozilla.org/Features/Security/Low_rights_Firefox comments/feedback welcome ! thanks, ian _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security -- Simon Bennetts Mozilla Security Team Twitter: https://twitter.com/#!/psiinon "The confidence that people have in security is inversely proportional to how much they know about it." _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
