FlowSafe: Difference between revisions
Jump to navigation
Jump to search
(→To-do) |
(→To-do) |
||
| Line 18: | Line 18: | ||
# Add <code>JSTrustLabel</code> to the JS API, a union of <code>JSPrincipals</code> (trust labels replace principals) | # Add <code>JSTrustLabel</code> to the JS API, a union of <code>JSPrincipals</code> (trust labels replace principals) | ||
# Have shapes imply trust labels so that distinct origins get different shapes for standard objects, equivalent property list patterns, etc. | # Have shapes imply trust labels so that distinct origins get different shapes for standard objects, equivalent property list patterns, etc. | ||
# Extend <code>JSExtendedClass</code> to delegate <code>typeof</code> so we can build <code>LabeledPrimitiveValue</code> wrappers for primitives | # Extend <code>JSExtendedClass</code> to delegate <code>typeof</code> so we can build <code>LabeledPrimitiveValue</code> wrappers for primitives | ||
| Line 24: | Line 23: | ||
# Interpreter <code>pc</code> has a <code>JSTrustLabel</code> | # Interpreter <code>pc</code> has a <code>JSTrustLabel</code> | ||
# Variable objects (even those optimized away) have a <code>JSTrustLabel</code> | # Variable objects (even those optimized away) have a <code>JSTrustLabel</code> | ||
# Add policy JS API that allows custom assignment, control flow branching, and input/output policy decision points -- does this mean SSA in one pass? | |||
# Add shell functions for testing and write tests | # Add shell functions for testing and write tests | ||
# DOM, other host objects have trust labels | # DOM, other host objects have trust labels | ||
# Exceptions, etc. | # Exceptions, etc. | ||
# Declassify primitive TBD, defer for now | |||
--[[User:Brendan|Brendan]] 02:07, 6 August 2009 (UTC) | --[[User:Brendan|Brendan]] 02:07, 6 August 2009 (UTC) | ||
Revision as of 01:27, 31 October 2009
FlowSafe: Information Flow Security for the Browser
The central idea is to improve the default browser security model, which is "stuck" since 1995 at the Same-Origin Policy with its underlying and conflicting DOM access control and JavaScript object-capability security layers.
We aim to do this without breaking the web, and indeed with measurable improvements to safety property enforcement and security policy expressiveness.
Goals
- Improve default cross-site script integrity (ads, analytics)
- Systematically enforce the Same-Origin Policy and better security policies by pervasive mediation
- Reduce existing "caps", DOM, and JavaScript engine patch-work / leaky reference monitor code
- Guarantee termination-insensitive non-interference for better confidentiality
- Explore timing and termination channel mitigations
To-do
Implement dynamic-only, fail-stop "no sensitive upgrade" or better, information flow security for JS, the DOM, and other parts of the browser. See this paper on part of the work.
- Add
JSTrustLabelto the JS API, a union ofJSPrincipals(trust labels replace principals) - Have shapes imply trust labels so that distinct origins get different shapes for standard objects, equivalent property list patterns, etc.
- Extend
JSExtendedClassto delegatetypeofso we can buildLabeledPrimitiveValuewrappers for primitives JSScripthas aJSTrustLabel- Interpreter
pchas aJSTrustLabel - Variable objects (even those optimized away) have a
JSTrustLabel - Add policy JS API that allows custom assignment, control flow branching, and input/output policy decision points -- does this mean SSA in one pass?
- Add shell functions for testing and write tests
- DOM, other host objects have trust labels
- Exceptions, etc.
- Declassify primitive TBD, defer for now
--Brendan 02:07, 6 August 2009 (UTC)
References
Efficient Purely-Dynamic Information Flow Analysis (PLAS '09)