B2G App Security Model/Threat Model: Difference between revisions

Jump to navigation Jump to search

B2G App Security Model/Threat Model (view source)

Revision as of 02:00, 16 March 2012

2,887 bytes removed ,  16 March 2012
Replaced content with " - DRAFT -"
No edit summary
(Replaced content with " - DRAFT -")
Line 1: Line 1:
  - DRAFT -
  - DRAFT -
==Threats Summary==
In order to discuss the permissions model for B2G, we need to discuss the threats posed. The following is a high level list of threats for further discussion:
=== Vulnerable Web App===
Web Application Vulnerabilities are commonplace, and with the increased capability permissions grant comes increased impact in a compromise scenario.
Examples:
* Web application security threats (XSS, SQLi, etc)
* Framework weaknesses (same-origin bypass, privilege escalation, abuse communication between apps?)
Countermeasures
* Security of web application and server could be under direct control of the store (e.g. a telco which hosts its own apps)
* Contractual controls with third parties
* C
===Malicious Web App===
Examples:
    - User tricked installing malicious application
   
Countermeasures
* Trusted stores pre-installed on the device
* Appropriate warnings and acknowledgements when adding new trusted stores
* Trust delegation model where store can trust other stores to grant only certain permissions (not all or nothing)
* Trusted UI for installing application
* Requirement for SSL for Apps granted permissions (Strict SSL even?)
===Network Compromise===
Web Apps are hosted remotely so network is a threat upon even launch. Even cached apps have their manifest checked upon each launch(?).
- Legitimate app is compromised at the network layer
    -
Compromised web app server for Web Apps hosted remotely
- Lost device
    - User data compromised
===Platform Vulnerabilities===
These style of attacks will largely fall out of the scope for the permissions model. The only consideration is how permissions are granted to Apps, and how these then translate into permissions being granted to processes. (See [[B2G/Architecture#Userspace_process_architecture]] for further details on B2G architecture.)
Examples:
* A memory corruption vulnerability that gives control of content process
* Attacks against other processes (media server, rild etc)?
Possible Countermeasures:
* Sandboxing content processes so the only action compromised process can do is send idpl messages back to B2G process . If we have a single process per App with effective sandboxing, the compromise would only grant the attacker access to the same permissions as what the app has. If device limitations force having more than one Web App per process, compromise of a single process would allow spoofing idpl messages with a union of all permissions granted to apps running in that process. Hence it may make sense to separate critical apps (dialer etc) from non-critical ones, at a process level. But on the assumption that all apps are granted permissions on a least privilege basis, then this threat doesn't have a strong bearing on how permissions are allocated to apps. Perhaps ensuring that permissions are granular enough to be segregated out to different applications.
Ptheriault
canmove, Confirmed users
1,220

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/408364"

Navigation menu