Security:Security Checks In Glue

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.

Conceptual description

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

 document.importNode(node);

This code needs to perform a security check to see whether document and node are same-origin. In this model, this check could be performed in the following places:

1. The code mapping Document.importNode to nsDocument::ImportNode
2. The implementation of nsDocument::ImportNode

The check could NOT be performed in nsNodeUtils::Clone, which is called by nsDocument::ImportNode to do the actual work of importing 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.

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.