17
edits
Mozilla2:CAPSSecurity: Difference between revisions
Jump to navigation
Jump to search
m
wikify, avoid html, to get OL types 1,A,i we need tweek wiki's style CSS
m (wikify, avoid html, to get OL types 1,A,i we need tweek wiki's style CSS) |
|||
| Line 40: | Line 40: | ||
Access to interfaces on XPCOM objects is currently managed variously by xpconnect and by objects through several mechanisms: | Access to interfaces on XPCOM objects is currently managed variously by xpconnect and by objects through several mechanisms: | ||
# Wrapper-creation check | |||
## get nsIClassInfo, check the flags for a DOM node. If it's a DOM node, you can have a wrapper. | |||
## else get nsISecurityCheckedComponent and check canCreateWrapper | |||
# xpconnect access checks go through nsIXPCSecurityManager CanAccess | |||
## Get the security policy of the current calling code (subject) | |||
## do same-origin checks if specified | |||
## reject access to anonymous content | |||
## check the object for nsISecurityCheckedComponent and ask the appropriate method for non-default permissions | |||
## There is a method nsIXPCScriptable.checkAccess which is never called. This seems suspicious to me. | |||
# Methods can perform additional customized security checks in method implementations through the scriptsecuritymanager. [http://lxr.mozilla.org/mozilla/source/content/html/content/src/nsHTMLInputElement.cpp#679 Example of fileinput.setValue doing its custom check]. | |||
''Note: I'm a little hazy on step 1a, I thought there was more to it, like a same-origin check.'' | ''Note: I'm a little hazy on step 1a, I thought there was more to it, like a same-origin check.'' | ||
| Line 71: | Line 64: | ||
This is my concept of '''The Rules''' for interacting between secured and unsecured code. | This is my concept of '''The Rules''' for interacting between secured and unsecured code. | ||
# Unsecured Code | |||
## Unsecured code may call other unsecured code without regard to the security stack. | |||
## When unsecured code calls secured code, it must initialize CAPS with a security stack. | |||
### This might be a simple stack of one principal (system principal or a codebase) | |||
### It could also be a stored stack. For instance, when a DOM timer is set, the DOM code will store the security stack. When the timer is fired, that same security stack will be used. | |||
# Secured Code | |||
## When secured code is called, it must have a valid security stack. If it doesn't, that's a design/security flaw. See the second bullet above. The secured code must then perform appropriate security checks. | |||
## When secured code calls secured code from another origin, The fooconnect for the new code must push the new origin onto the stack. | |||
## Secured code may Assert privileges that it needs by pushing them onto the stack. It must pop these privileges off before returning. (Assert is the CAS equivalent to enablePrivilege()). | |||
### This needs to be exposed to FooConnect code through an object Components.security or somesuch. Or maybe just keep using netscape.securitymanager, need to investigate. | |||
### need a stack-based C++ wrapper for this, so that early returns clean up asserts properly | |||
## Secured may only call unsecured code if the secured code currently has the system/universalxpconnect privilege. At this point, the security context is invalid and must not be used. We probably want to explicitly invalidate the security stack, at least in debug builds, to catch logic errors. | |||
=== Defining Secured Code === | === Defining Secured Code === | ||
| Line 140: | Line 121: | ||
When unsecured code is finished with the stack frame that calls CAPS_StartStack, it calls CAPS_EndStack to clean up. | When unsecured code is finished with the stack frame that calls CAPS_StartStack, it calls CAPS_EndStack to clean up. | ||
When performing a security check, call CAPS_CheckAccess(origin, named-privilege). For example, to see if the calling code has access to read the DOM of a page at http://www.foo.com, call CheckAccess([origin of http://www.foo.com], "read"). | When performing a security check, call CAPS_CheckAccess(origin, named-privilege). For example, to see if the calling code has access to read the DOM of a page at http://www.foo.com, call CheckAccess([origin of http://www.foo.com], "read"). | ||
When secured code calls unsecured code, it calls CAPS_SuspendStack. When it is finished calling unsecured code, it calls CAPS_ResumeStack. | When secured code calls unsecured code, it calls CAPS_SuspendStack. When it is finished calling unsecured code, it calls CAPS_ResumeStack. | ||
Here are a list of the possible named-privileges I know we need so far (I'm sure there are more): | Here are a list of the possible named-privileges I know we need so far (I'm sure there are more): | ||
* "read" (read the DOM or other content belonging to the origin) (UniversalFileRead would be CAPS_CheckAccess([origin for file://], "read")) | * "read" (read the DOM or other content belonging to the origin) (UniversalFileRead would be CAPS_CheckAccess([origin for file://], "read")) | ||