Security:Scattered Security Checks: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 2: Line 2:


This is a proposal for a security model for Gecko.  The key idea of this proposal is that security checks are performed immediately before doing a possibly-unsafe operation and that the subject principal for any actions is tracked throughout the codebase.  Contrast this with the proposal at [[Security:Security_Checks_In_Glue]].
This is a proposal for a security model for Gecko.  The key idea of this proposal is that security checks are performed immediately before doing a possibly-unsafe operation and that the subject principal for any actions is tracked throughout the codebase.  Contrast this with the proposal at [[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.


= Conceptual description =
= Conceptual description =

Revision as of 22:19, 12 September 2006

Abstract

This is a proposal for a security model for Gecko. The key idea of this proposal is that security checks are performed immediately before doing a possibly-unsafe operation and that the subject principal for any actions is tracked throughout the codebase. Contrast this with the proposal at 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.

Conceptual description

In this model, security checks are performed as needed in the code flow. For example, before setting some internal member of a class, we could check whether the caller is allowed to set it. This model requires keeping track, throughout our code, of who "the caller" is. This is more or less the current model, except we pretty much completely screw it up.

Pros and cons

The main benefit of this model is that at first glance it promises more conservative behavior than the Security:Security_Checks_In_Glue model. The failure cases are mostly cases where permission is denied when it should be granted.

There obvious drawback is that you have to keep track of who "the caller" is (the subject principal) at all times. There are several parts to this. First of all, the subject principal needs to be propagated through various parts of the code. Second, the current subject principal needs to be switched as needed (e.g. when code is no longer acting on behalf of the current subject). Clearly defining when to switch principals is hard; it seems like it would be easy to have errors both of omission (not switching principal when one should; breaks web compat) and commission (switching principal when one should not; causes security bugs).

I question whether the perceived benefit of this model is in fact realized, given the complexity of changing the subject principal at just the right time.

Implementation notes