User Tools

Site Tools


projects:policy_discussion

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
projects:policy_discussion [2010/05/25 14:21]
taustin
projects:policy_discussion [2010/05/25 15:49]
cormac
Line 2: Line 2:
  
 ===== Information Flow Channels ===== ===== Information Flow Channels =====
-In this section we are trying to highlight various fields in JavaScript that an attacker can use to transmit information. We distinguish between immediate channels where modifying this fields sends information to an attacker and delayed channels were no information is sent to the attacker until the user performs some action+In this section we  highlight various fields in JavaScript that an attacker can use to transmit information. We distinguish between immediate channels where modifying this fields sends information to an attacker and delayed channels were no information is sent to the attacker until the user performs some action.
- +
-Confidential information should not influence any of these fields, unless they come from the same origin as the confidential data.  (But note that exfiltration attacks can make this unsafe as well, unless there are some safeguards taken).+
  
 ==== Delayed Channels ==== ==== Delayed Channels ====
Line 24: Line 22:
  
 ===== Storage ===== ===== Storage =====
-For storage channels data is not directly transmitted to an outside source, ​however ​any security labels need to be persisted along with the data or these need to be delayed channels.+For storage channels data is not directly transmitted to an outside source.  However, any security labels need to be persisted along with the data or these need to be treated like delayed channels.
   * cookies   * cookies
   * window.name   * window.name
Line 32: Line 30:
  
 ===== Security Lattice ===== ===== Security Lattice =====
-We assume that each origin may be its own security principal. In addition we have a LOCAL_ONLY ​label for data that should never leave the client. ​+For confidentiality,​ we assume that each origin may be its own security principal. ​ 
 +We note that '​http://​ucsc.edu'​ and '​http://​soe.ucsc.edu'​ are different principals,​ 
 +as are '​http://​ucsc.edu'​ and '​https://​ucsc.edu'​. 
 +In addition we have a LOCAL_ONLY ​principal ​for data that should never leave the client. ​
  
 +In order to safely handle exfiltration attacks, we will also need a notion of integrity. ​ For all data, we will need to track which principals have influenced the data.  (Note that without declassification,​ the moment that more than one principal have affected any confidential data item, it becomes LOCAL_ONLY).
  
 ===== Confidential Fields ===== ===== Confidential Fields =====
Line 63: Line 65:
 In order to defend against these attacks, we will need to add a notion of integrity. ​ Confidential data can only be sent back to its origin if the decision to do so was not influenced by any other principal. ​ (This solution is one proposed for safe declassification). In order to defend against these attacks, we will need to add a notion of integrity. ​ Confidential data can only be sent back to its origin if the decision to do so was not influenced by any other principal. ​ (This solution is one proposed for safe declassification).
  
-We note that cross-site loading tags might not require this restriction,​ since it does not seem likely that an attacker can learn information ​by loading data from someone else's servers. +We note that cross-site loading tags (e.g. image tags) might not require this restriction,​ since it does not seem likely that a site would use these tags to pass information ​between accounts.
projects/policy_discussion.txt · Last modified: 2010/05/25 15:49 by cormac