Abstract

This is a proposal for a security model for Gecko. The key idea of this proposal is that all security and access checks are performed immediately upon entry from JavaScript into C++ code. Contrast this with the proposal at Security:Scattered_Security_Checks.

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:

 window.status = "Status";

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, this check could be performed in the following places:

1. The code mapping Window.status to nsGlobalWindow::SetStatus.
2. The implementation of nsGlobalWindow::SetStatus.

The check could NOT be performed in nsIWebBrowserChrome::SetStatus, which is called by nsGlobalWindow::SetStatus to do the actual work of setting the status in this case.

In general, in this model there is a concept of "the function currently being called from JS". This function is the only function that does security checks.

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 very fast.

The most obvious drawback is that you don't get a defence-in-depth setup. That is, once something gets into C++ code, there are no more security checks. This means that JS-accessible methods have to be written with a bit of care, with all codepaths out of them examined and corresponding security checks done up front.

(We can use Oink and Cqual++ [1] with qualifiers we use to decorate the glue code, and statically check for bad code paths. /be)

Implementation notes

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

1. Ditch XPConnect for DOM classes. Use glue code, automatically generated as needed, instead. Do some security checks in the glue.
2. Do the remaining security checks at the very beginning of the DOM methods themselves, but only if the method is the one that's currently being called by the glue (that is, method name and |this| pointer match). This doesn't handle reentry of the method from other parts of the code while it's being called... not sure what we can do about that. This could probably be done without ditching XPConnect, if we used the XPCCallContext stack or something to check what the currently-called method is.
3. 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.