Component Security for MozillaMitch Stoltz
Hackers point out that it is vendors, not they, who are responsible
for the gaping holes that permeate so many products. With companies releasing
software as fast as possible, proper security often gets lost in the rush
toward store shelves.
complexity increases, the opportunity for vulnerability
increases says Steven Foote, a senior vice president at the Hurwitz Group,
which analyzes strategic business applications. -- U.S. News, Can
hackers be stopped?
Mozilla will make increasing use of Internet technologies to implement the browser itself. This has many benefits for modularity, cross-platform development, and encouraging development by a wider range of people. However, it also makes the process of ensuring browser security more challenging because the lines distinguishing the trusted browser from the untrusted content it displays have become blurred.
Eventually we will need a full capabilities system similar to what Java has reached in Java2. However, given the need to ship quickly, we should implement a simpler binary trust model. All code used to implement the browser should be given full privileges, while the privileges of any code from off the net should be limited as it was in 4.x.
I'm proposing the following limitations to the capabilities of web-based code:
- No web-based XUL
- No direct access to RDF
- Chrome only runs from the local filesystem (i.e., no downloadable chrome, only installable chrome)
- Limited access to XPConnect components--most components will not be accessible from web content, and those that are accessible must undergo security review
- No access of web content to the surrounding chrome
These limitations serve to make the system simpler and more secure.
Distinguishing types of code
The DOM should implement the security model from 4.x (at least the unsigned part). Historically the DOM has been the area with the most public exploits, so security implementation here will need careful review.
There are several proposals for additions to the 4.x DOM security model. Researchers from Bell Labs have proposed several new features, most notably domain-specific policies. There's a similar proposal described and elaborated in Bugzilla bug 858.
Since XUL is used to implement chrome, it needs access to highly privileged services. All code in chrome should be trusted, which means that installing code into chrome is a privileged action. Note that skins don't contain any code and should be safe to install without any heavy safeguards.
Many RDF data sources reflect security assets. Most obvious is the filesystem, but others like the chrome registry have security implications as well. We should prohibit direct access to RDF from untrusted code.
New DOM APIs
Not sure what's here.... joki will help.
Chrome registry API
This is an API that allows web pages to request adding XUL files to chrome.