Abstract

This is a proposal for a wrapper-based security model for Gecko. The key idea of this proposal is that all necesary security and access checks are performed by wrappers (aka proxies or brokers) that enclose assets from a trust domain other than the one of the code manipulating the wrapper. Contrast this with the proposals at Security:Scattered_Security_Checks and Security:Security Checks In Glue.

This proposal does not address Python and other languages, but they are identical to C++ for purposes of this proposal.

This proposal also does not address scriptability in general but is rather limited to "DOM" objects (which are actually exposed to web pages).

Conceptual description

In this model, security checks are performed only at known entry points from JavaScript into C++. For example, consider the following JavaScript:

 win.status = "Status";

where win refers to a DOM window object.

This code needs to perform a security check to see whether the caller is allowed to change the text in the status bar. In this model, the check must occur only if the current script is from a different trust domain (labeled by origin for the same-origin model) from the document loaded in the window object (which with inner windows is the same as the trust domain of the window object).

The check should NOT be performed in any of these places:

1. The code mapping Window.status to nsGlobalWindow::SetStatus.
2. The implementation of nsGlobalWindow::SetStatus.
3. The implementation of nsIWebBrowserChrome::SetStatus, which is called by nsGlobalWindow::SetStatus to do the actual work of setting the status in this case.

In this model there is a concept of "the current script", which could be a function. The trust domain label for the current script is called the subject principal for historical reasons. Likewise, the trust label for the window object is an object principal.

Pros and cons

There are several benefits to this approach. First, it's reasonably simple to implement. Second, it eliminates action-at-a-distance issues like Bug 287446. Third, it should be possible to make this extremely fast, especially for the same-origin case (subject and object principals match) -- even by use of JIT compilation.

The most obvious drawback is that you don't get defense-in-depth. That is, once something gets an unwrapped object from a different trust domain, there are no more security checks. This means that cross-domain-accessible DOM methods (e.g., window.open) must be written with great care to wrap any results passed back to another origin.

Implementation notes

The most straightforward way to do this would be the following:

1. However we implement the DOM for the same-origin case, implement yet another wrapper class that does the appropriate security checks.
2. Examine all checks that use the subject principal in our current codebase and make sure that equivalent checks are being performed in the new model.