Apps/Security: Difference between revisions

Jump to navigation Jump to search

Apps/Security (view source)

Revision as of 00:04, 13 March 2012

4,313 bytes added ,  13 March 2012
no edit summary
No edit summary
Line 1: Line 1:
== API permissions ==
= Boot 2 Gecko / OpenWebApps Security Model =
=== Dataflow ===
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}
[File:WebApp_DFD.png]
== Requirements ==
=== Distribution / management of WebApps ===
# It should not be trivially easy for a rogue application to be listed on a marketplace / store
# A store may revoke a bad / malicious WebApp
# A telco can decide which stores to implicitly trust on their devices
=== Management / granting of API permissions to WebApps ===
# User should be able to view / control / modify permissions granted to WebApps
# WebApps should fail gracefully if not all permissions granted
# User should have control over APIs with privacy implications
=== Enforcement of permissions on device ===
# Permissions should be enforced regardless of version of B2G installed


=== What are we trying to solve? ===
== Proposals ==
We want to define API permissions taking into account the follow threats
=== Trusted store with permissions delegation ===
# How to protect user from malicious app
* Mozilla (telco store) acts as an authority for permissions requests
#* An app should not be able to perform more than it's manifest specifies
* WebApps request permissions in manifest
# How to protect user from MITM attack
* Each store contains a set of permissions they can grant
#* This may result in a malicious app scenario
* The "root" store may grant any permissions
#* We don't want to leak a user's personal information (contacts, messages, voicemail, etc)
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions
** ACME is a root store
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant
** WidgetIncApp is listed on ACME store
** WidgetIncApp requests Hammer, Nail permissions
** ACME store has been granted Hammer, Screw permissions by telco
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer
** "blessed" apps must always be served from the store with access to source code
* Selfhosting of WebApp
** A WebApp can be self-hosted and query a trusted store on install
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp
*** WidgetInc wants to host WidgetIncApp from widget.lol
*** WidgetInc has already uploaded WidgetIncApp to ACME Store
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===
* Tested architecture that is used SELinux
* Follows a mandatory access control model where no permissions are granted by default
* There is no inheritance of ACLs / permissions
** If a WebApp were to change / do something new, it wouldn't have its old permissions
* "what you can do depends on who you were, where you are *AND* what you're executing."
* Adopting for use in B2G means writing an interface that mediates API / systemcalls
** Suggestion was a JSONRPC service
* API access would be enforced across security contexts
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.


=== Proposed solution ===
=== Debian Keyring (Package Management) for distribution of apps ===
* APIs should have separate permissions for read and write/modify.
* Items in () denote the equivalent in WebApp world
** e.g. an app that only needs to check call state does not need access to perform calls
* infrastructure already exists
* APIs that need internet access should define what domains they need to talk to
* Code is cryptographically signed by multiple parties
* Manifest should be served over SSL
** Package (WebApp) maintainer (author / company)
** doesn't protect against a compromised cert
** Package is signed by FTP masters (marketplace / store?)
** cert pinning may be a solution
* Signed packages / manifests are separate from binaries (HTML content)
* Manifest should be signed
** We need a way to verify that the WebApp content has not changed
** this will provide some "authenticity" in the event the developer doesn't use SSL
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)
** perhaps hash with shared secret between developer and appstore?
* A user may choose to add more sources (stores)
* The rules can be relaxed depending on the set of permissions requested by the manifest
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source
** Dialer app that only requests access to telephony and contacts
*** If the app doesn't request permissions to write/send the data, we may not require the app to be served over SSL (though manifest would still have to be secured)
*** if a MITM does occur in this case, an attacker can't send the data anywhere


=== Sensitive APIs ===
=== Permissions manager ===
* Telephony
* User can deny permissions at install time
** potential for fraud
* User can always go to manager to see what permissions an app has been granted
* WebSMS
* User can modify permissions through the manager
** potential for fraud
* Certain APIs are defined as "sensitive"
* Contacts
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi
** personal information
* Levels of access for capabilities
** Allow
** Prompt (default to remember)
** Prompt (default to not remember)
** Deny
*** There were concerns that the levels should only be Allow/Deny
* Contractual enforcement of permissions
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions
* WebApps may be granted default permissions
** e.g. access to storage, access to change context menu
* capabilities may be restricted based on technical restrictions of the site
** e.g.  strict-transport security, EV-certificate
 
=== Other (topics that don't fall into above proposals) ===
* SSL should be used for content delivery
** can provide authentication for client-store communication
** provides end-to-end security
** does not address concerns of a malicious app
* W^X / NX for WebApps
 
== Open questions ==
# What happens when a WebApp is revoked?
#* removed from store?
#* removed from user device?
#* refund?
# What is the identifier used when a WebApp is revoked?
#* origin (scheme + host + port)
#* certificate / hash embed inside WebApp manifest
# Should eval() and similar functions be considered sensitive APIs / restricted?
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]
# Should self-signed certificates be allowed?
Dchan
Confirmed users
110

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/406730"

Navigation menu