Apps/Security/Permissions: Difference between revisions

From MozillaWiki
< Apps‎ | Security
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
= Permissions Definitions and Presentation =
{{note|Please do not edit this page.  Share your ideas in dev-webapps@lists.mozilla.org or [[Apps/Security/Discussion]] instead}}


This section discusses the actual permissions to be enforced (as distinct from the [[Apps/Security/Enforcement|method of enforcement]], how and what should be presented to the user, including the management, and the implications at the application level (if permissions are or are not granted).
{| border="1"
 
|+ Web Content (not exhaustive)
== Scope ==
|-
 
! API!!Action!!Explicit!!Visual Indicator
===Process for granting permissions===
|-
#By default all Web Apps have the no special permissions, the same as any other web page.
| Screen Orientation||lock screen orientation, detect changes||No||No
#A Web App requests permissions in the manifest when submitting to a store (an application may only be granted permissions that it requests in the manifest)
|-
#An App Store can grant permissions to a Web App during the install process (but not necessarily all of the requested permissions
| Vibration API||||No||
#The user’s default permission policy is applied to the requested permissions (see permissions management) and requested permissions are updated
|-
#The user is informed of the permissions during installation, and can modify them if desired, or choose to trust the defaults set by the App Store.
| IdleAPI||Detect user inactive||Yes||No
 
|-
Note: If sensitive permissions are requested, certain security requirements may be placed on the application.
| ResourceLock API||Prevent the screen from being dimmed or switched off||No||No
 
|-
(''comment: this section appears to be in discussion or proposal form, not a summary form. as such it should be moved to a suitable section'')
| Geolocation API||Obtain current location of user||||
 
|-
 
| Mouse Lock API||Lock access to mouse and get access to movement deltas rather than coordinates.||Yes||No
=== Types of Runnables ===
|-
The scope of the permissions model is limited to Open Web Apps, which are applications written web technologies (HTML, JS, CSS).
| Network Information API||Get basic information about current network connectivity.||No||No
These are the only applications which are installed on B2G, "the web is the platform", there are no user-installable native apps.
|-
 
| Battery Status API||Information about battery charge level and if device is plugged in.||No||No
There are multiple layers of applications underneath these web apps, which make up the B2G OS, but these are beyond the scope of the permissions model. It is noted however that the permissions model might influence the design of lower layers: for example, ideally Web Apps of differing permission levels would be sandboxed to limit the impact of memory corruption vulnerabilities. For further detail on the underlying B2G architecture see: [[B2G/Architecture]]
|}
 
== Requirements ==
 
===Permission Types===
#For privacy-related permissions, the user must always be asked, unless they have overridden
#Permission values:
##Deny
##Prompt (default to remember)
##Prompt (default not to remember)
##Allow
#List of Permissions: TBD
 
=== 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
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)
# Apps must not request permission to do something or use a function that it has not declared that it needs to do.  ('''TBD: If an app attempts to execute a function which the user has not authorised, what action should be taken? terminate the app? remove it? report it?''')
 
discussion links:
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE
 
===Management of Permissions===
#A user can modify the permissions granted to a Web App at any time including granting or revoking privileges
#Permissions can be granted per application, or set globally in the Default Permission Policy (see below)
#Users need to be guided on the consequence of changing permissions, and protected from making choices which are insecure or which could disable their device (e.g. removing the permissions setting capability from the permissions web app)
#Permissions can be modified either through a permission manager application, or set through contextual actions (e.g. response to security prompts including "remember me" checkboxes or through behavior in some cases, e.g. user ignores a prompt five times in a minute, don't prompt again for an hour)
 
===Default Permission Policy===
Each B2G device has a default permissions policy which takes precedence over the app store. This is expected to contain rules for a subset of permissions.Its purpose is:
*for device manufacturers to set safe default limits for permissions
*for users to decide on global limits for permissions
For example, a default setting for location might be that even apps, which are granted access to location, must always ask the user. This could modify this policy to be more strict, and globally deny applications from accessing location information.
 
A user should be warned before they override the Default Permission Policy in an unsafe way.
 
=== Required Application Permissions ===
 
This section lists the actual permissions that are required to be enforced (at the Operating System Level)
 
* Full-screen mode
** Interaction (events allowed and to which areas?)
* Phone Access
** Emergency Services
** Ordinary calls
** Premium Rate numbers (?)
* SMS
** Read
** Send
** Delete
** Address book read
** Address book modify
* GPS
* EMEI Number
* Camera
* USB devices
* Access to bluetooth
 
== Proposals ==
=== Capabilities Model: Absolute Minimalist (no) Permissions presentation to Users ===
One major concern is that users simply do not have a clue what they are doing.  The "click the box" syndrome.  It therefore makes some sense to simply not present any permissions dialogs ''at all'' to the user, but instead for all decisions, all warranties and all reviews regarding the security and privacy of an application to be made by the Mozilla Foundation, the application developer and the store(s).
 
Whilst at '''no time''' will an application '''not''' receive a full review and security audit, and whilst there would still be a complete and full set ''of'' permissions, the proposal is simply that the user is simply given one choice: install application based on what it says that it does, or don't install application.  The user can read up on the application's capabilities, must agree to its license, and no more.
 
Under these circumstances, variants of the application may be released, as well as plugins to that application, which extend its capabilities.
 
This is known as a "Capabilities Model", as an alternative to "Access Control".  If a user is not permitted or is not to be given a choice to carry out certain functions, under the "Capabilities Model", the functionality is '''removed''' i.e. not even present on the system ''at all''.
 
Note that under Debian (apt) and Redhat (or other yum-based) package management systems, "meta-packages" can be created which depend on the various plugins, making it possible for users to choose a "single application" which installs absolutely every single "plugin".  This makes their lives much easier, whilst at the same time protecting the security and respecting the wishes and privacy of users.
 
The overall effect is exactly the same as the "permissions system" but the user is protected by the fact that code which they do not want on their system simply is not even present.
 
=== Permissions manager ===
* User can deny permissions at install time
* User can always go to manager to see what permissions an app has been granted
* User can modify permissions through the manager
* Certain APIs are defined as "sensitive"
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi
* 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

Revision as of 19:05, 8 May 2012

Note: Please do not edit this page. Share your ideas in dev-webapps@lists.mozilla.org or Apps/Security/Discussion instead
Web Content (not exhaustive)
API Action Explicit Visual Indicator
Screen Orientation lock screen orientation, detect changes No No
Vibration API No
IdleAPI Detect user inactive Yes No
ResourceLock API Prevent the screen from being dimmed or switched off No No
Geolocation API Obtain current location of user
Mouse Lock API Lock access to mouse and get access to movement deltas rather than coordinates. Yes No
Network Information API Get basic information about current network connectivity. No No
Battery Status API Information about battery charge level and if device is plugged in. No No
Retrieved from "https://wiki.allizom.org/index.php?title=Apps/Security/Permissions&oldid=428718"