Security/B2G/PermissionReview

From MozillaWiki
< Security‎ | B2G
Jump to: navigation, search

Exposing Privileges to the Web

The basic problem is that web content is completely untrustworthy, so our APIs are too dangerous to expose to such content. Current Certified/Privileged APIs can need to be made safer through a combination of:

  • only exposing safe parts of APIs
  • adding mitigating controls to APIs
  • creating more specific APIs to safely solve use cases
  • creating more sophisticated security UI
  • mandating adoption of existing web security controls (TLS, CSP etc)

General Security Requirements

The following requirements are high level, and there are exceptions, but these are the sorts of things which currently prevent certified & privileged APIs from being more widely exposed.

  • Avoid fingerprinting: don’t expose unique user or device identifiers (especially permanent hardware addresses)
  • Prevent access to underlying OS & data - all access must be mediated by user (e.g. file input)
  • Prevent direct access to local devices - access mediated by the user (e.g. navigator.getUserMedia)
  • Cause system instability due to resource consumption (CPU, bandwidth, disk space, battery etc)
  • Limit network connectivity to protect local networks (same-origin policy, port limitations etc)

API Categories

In going through all of the permissions, some categories of APIs emerged, with each category having differing security control options.

Device Access

A number of FxOS are created to provide access to various hardware devices: e.g. Bluetooth, NFC, Motion Sensors, fmradio, wifi. Making these more safe depends completely on the device being accessed. Relatively safe devices like motion sensors and fmradio only pose a mild privacy risk and could perhaps be mitigated user mediation (prompts). But devices like bluetooth & nfc are significantly more complex. The W3C bluetooth group has a good enumeration of privacy & security risks [5] for just BluetoothLE. The approach they have taken is to abstract away detail, and provide high level APIs which don’t have the same security risks as the low-level hardware APIs. For example, instead of exposing an API which allows control of bluetooth adaptors (like how mozBluetooth currently does) expose a service which allows connected to a remote service like “heart-rate monitor”. See [6] for an example.

Data Access

Some APIs provide direct access to local data stores, e.g. contacts, Device-Storage (pictures, video, music, sdcard). Access can be read-only or full read/write access. There are several things to consider here:

  • a user might grant pictures access at a time when they don’t have any private photos, but forget to revisit that decision later after taking photos that are more sensitive
  • access can permanently destroy data
  • if website XYZ gets hacked, the hackers gain access ALL data for ALL users, not just the data the user has uploaded to the website. Basically the user needs to understand that by granting the permission, they are effectively uploading ALL of their data onto the app’s service.

Mitigation suggestions:

  • silo data: e.g. put photos in albums, and allow users to only grant access to specific photos or albums
  • make web APIs data safe: prevent overwrite and make delete “move to trash folder” instead so user can always recover data
  • Provide auditing so users can trace what app access

Unrestricted network access

Some APIs provide local network access - e.g. SystemXHR, tcp-socket & udp-socket. These are very commonly requested APIs (in marketplace stats, but also anecdotally on list and dev meetups). The risk is that untrusted web code will access internal systems that were not intended to be exposed to the internet. There have been some suggestions around solving the single server access case, but the general case of allowing unrestricted network access is problematic.


Detailed Analysis:

Push Events & Notifications

Ability to receive push events, and display notifications to the user. We already provide access to “push” permission. Why is wappush more restricted? How do extend support to the web, not just web apps?

Audio Control

The main audio related risks are annoyances and DoS of vital telephone services. These are likely solvable using a combination of granting priority for system/certified applications and also figuring out a safe way for a user to switch audio priority to 3rd party apps. NB currently competing audio policy is only allowed between loop and the dialer and requires both to co-operate. We need a solution for hostile or poorly implemented apps.


SMS

SMS is risky mainly due to the cost involved. Risks include cost of sending SMS, SMS often used in 2-factor auth (e.g. banking)

But there are different use cases. For example, many use cases just need the ability to receive SMS - instead of granting SMS permission, we could expose a read-only SMS datastore which other apps could observe changes on which removes the cost risk (but not the sensitive data risk).

Telephony & Mobile

Telephony & mobileconnection seem more dangerous - not sure that there is a strong use case here? Thoughts? Do you really want websites making phone calls, locking your SIM card?

Applications vs API usage

With the target of making as many apps as possible hosted, an analysis has been carried out to check what are the Gaia Application dependencies on the FirefoxOS APIs.

The idea is identifying which APIs are used by every application and why are those APIs required (i.e. what is the purpose of using that API).

The ultimate target is checking if the Apps could be developed as hosted by:

  • Reducing functionality
  • Exposing APIs to hosted content currently not available to it (it might require splitting current APIs in smallest pieces)
  • Access to the functionality by alternative mechanism without using an API (e.g. Activities, Services…)

NOTE: There are some scripts that allow to automate part of this process and generate automatically the application vs. permission matrix and the Security Domain vs. APIs matrix. The scripts are available at (https://github.com/mcjimenez/appsVSperms).

Music Application

Music app is declaring the following permissions in its Manifest:

  • "audio-channel-content"
    • Ok, This permission is allowed to hosted content without any special prompt.
    • It’s used for playing music.
  • "device-storage:pictures" and "device-storage:music" with "readwrite" access
    • These permissions area allowed to Trusted Hosted Content with a Prompt action so we assume an equivalent solution to expose this API to hosted apps would be available. Although this API was opened to Trusted Hosted Apps, Music Application was requiring Read/Write access, and we should reconsider if there is any way to expose read access to Music Content in a more secure way.
    • They are required to access the music content and artwork.
    • NOTE: Need to assess what would happen if user denies the permission.
  • "nfc-share"
    • NOT OK for hosted: only available to certified apps.
    • Enable an app to transmit data to other devices via near field communication.
  • "bluetooth"
    • NOT OK: CERTIFIED API only.
    • Used for music remote controls. The code looks to be shielded (when API is not available the application should work without any issue at all)
  • "themeable"
    • NOT OK: CERTIFIED
  • "settings - readonly"
    • NOT OK: CERTIFIED API only.
    • Used for a hack to avoid an issue in a corner-case (Bug 95681): "If we are currently playing music and share the music with an inline activity handler (like the set ringtone app) that wants to play music itself, we have a problem because we have two foreground apps playing music and neither one takes priority over the other".
      • Opened Bug 1135680 to allow competing for the content audio channel in order to decouple the Music application from the Settings one. It seems that the new Audio Channel API will handle the issue (Spec included in Bug 961967)

How can make Music a hosted app?

Lets focus on the 4 APIs not open to hosted content yet:

  • Settings: This should not be problematic as the hack should disappear in 3.0 timeframe. The idea is removing this hack when Bug 1135680 is completed (to allow competing for the content audio channel in order to decouple the Music application from the Settings one). The new Audio Channel API will handle the issue although it's still in a premetaure state (Spec included in Bug 961967).
    • The immediate approach for testing/prototyping is just disabling this hack.
  • Themeable: Does not seem like a essential feature for the application functionality so this can be disabled without impacting end-user in the short term.
    • In the longer term, it does not seem like a dangerous feature to be used by hosted app that want to use the device theme. We should explore if this could be open to other apps.
  • NFC: The NFC API is used just for sharing content. So far no FxOS commercial devices support NFC and for a hosted version of the app, the immediate approach would be just disabling this feature as if the device did not support NFC. **In the longer term, we should assess if parts of the NFC funcionality could be exposed to hosted content or there are different ways to access to use this functionality.
  • Bluetooth: This API is used for controlling the player by a remote control. Again, in the short term, disabling this feature seems like a good compromise. In the mid term we need to assess whether this Bluetooth functionality could be exposed to hosted content (not all the functionality but part of it).

In conclusion:

  • There are just a couple of APIs that are not exposed to hosted content and that could reduce the functionality of a Music Hosted App: Bluetooth and NFC. For experimenting purposes we are disabling that functionality from the apps,but we should explore if there is any way to expose that functionality to hosted content, either by opening part of these APIs only or by using a service that expose the functionality (instead of exposing APIs).
  • Think about how the themeable capability could be used by any app willing to be “themed”.
  • Audio/Settings hack should be removed when the new Audio Channel Policy is implemented.
  • Device Storage: Read/Write: This should be re-assessed as the protection defined for Trusted Hosted Apps does not seem to be enough from a security point of view.

An example of the possible temporary hosted app following this approach is available at: https://github.com/telefonicaid/gaia/tree/hosted-web/apps/music

Video Application

Video app is declaring the following permissions in its Manifest:

  • "audio-channel-content"
    • Ok, This permission is allowed to hosted content without any special prompt.
    • It’s used for
  • "device-storage:pictures" and "device-storage:music" with "readwrite" access
    • These permissions area allowed to Trusted Hosted Content with a Prompt action so we assume an equivalent solution to expose this API to hosted apps would be available. (Although this API was opened to Trusted Hosted Apps, Video Application was requiring Read/Write access, and we should reconsider if there is any way to expose read access to Video Content in a more secure way. )
    • They are required to access the video content and
    • The read video permission is required to be able to read the videos, list and play them. The write permission for the pictures is used to operate with the videos thumbnails, e.g. Remove a video thumbnails.
    • NOTE: Need to assess what would happen if user denies the permission.
  • "nfc-share"
    • NOT OK for hosted: only available to certified apps.
    • Enable an app to transmit data to other devices via near field communication.
  • "themeable"
    • NOT OK: CERTIFIED

How can make Video a hosted app?

Lets focus on the APIs not open to hosted content yet:

  • Themeable: Does not seem like a essential feature for the application functionality so this can be disabled without impacting end-user in the short term.
    • In the longer term, it does not seem like a dangerous feature to be used by hosted app that want to use the device theme. We should explore if this could be open to other apps.
  • NFC: The NFC API is used just for sharing content. So far no FxOS commercial devices support NFC and for a hosted version of the app, the immediate approach would be just disabling this feature as if the device did not support NFC.
    • In the longer term, we should assess if parts of the NFC funcionality could be exposed to hosted content or there are different ways to access to use this functionality.

In conclusion:

  • There is just one APIs that is not exposed to hosted content and that could reduce the functionality of a Video Hosted App: NFC. For experimenting purposes we are disabling that functionality from the apps,but we should explore if there is any way to expose that functionality to hosted content, either by opening part of these APIs only or by using a service that expose the functionality (instead of exposing APIs).
  • Think about how the themeable capability could be used by any app willing to be “themed”.
  • Device Storage: Read/Write: This should be re-assessed as the protection defined for Trusted Hosted Apps does not seem to be enough from a security point of view.

An example of the possible temporary hosted app following this approach is available at: https://github.com/telefonicaid/gaia/tree/hosted-web/apps/video

Gallery Application

Gallery app is declaring the following permissions in its Manifest:

  • "audio-channel-content"
    • Ok, This permission is allowed to hosted content without any special prompt.
  • "device-storage:pictures" and "device-storage:videos" with "readwrite" access
    • These permissions area allowed to Trusted Hosted Content with a Prompt action so we assume an equivalent solution to expose this API to hosted apps would be available. Although this API was opened to Trusted Hosted Apps, Gallery Application was requiring Read/Write access, and we should reconsider if there is any way to expose read access to Gallery Content in a more secure way.
    • They are required to access the gallery content and artwork.
    • NOTE: Need to assess what would happen if user denies the permission.
  • "nfc-share"
    • NOT OK for hosted: only available to certified apps.
    • Enable an app to transmit data to other devices via near field communication.
  • "feature-detection"
    • Ok: This permission is allowed for privileged apps and has been allowed for Trusted Hosted apps.
    • Used for detect the device memory. We make the app exit if it goes to the background while scanning and if the device has 256mb or less of memory.
    • This permission is used for a temporary workaround to bug 1039943 (https://bugzilla.mozilla.org/show_bug.cgi?id=1039943)
  • "themeable"
    • NOT OK: CERTIFIED

How can make Gallery a hosted app?

Lets focus on the APIs not open to hosted content yet:

  • Themeable: Does not seem like a essential feature for the application functionality so this can be disabled without impacting end-user in the short term.
    • In the longer term, it does not seem like a dangerous feature to be used by hosted app that want to use the device theme. We should explore if this could be open to other apps.
  • NFC: The NFC API is used just for sharing content. So far no FxOS commercial devices support NFC and for a hosted version of the app, the immediate approach would be just disabling this feature as if the device did not support NFC.
    • In the longer term, we should assess if parts of the NFC funcionality could be exposed to hosted content or there are different ways to access to use this functionality.
  • Feature-detection

In conclusion:

  • There is just one APIs that is not exposed to hosted content and that could reduce the functionality of a Video Hosted App: NFC. For experimenting purposes we are disabling that functionality from the apps,but we should explore if there is any way to expose that functionality to hosted content, either by opening part of these APIs only or by using a service that expose the functionality (instead of exposing APIs).
  • Think about how the themeable capability could be used by any app willing to be “themed”.
  • Device Storage: Read/Write: This should be re-assessed as the protection defined for Trusted Hosted Apps does not seem to be enough from a security point of view.
  • Feature-detection: We should work on develop a patch for https://bugzilla.mozilla.org/show_bug.cgi?id=1046995

An example of the possible temporary hosted app following this approach is available at: https://github.com/telefonicaid/gaia/tree/hosted-web/apps/gallery

Camera Application

Camera app is declaring the following permissions in its Manifest:

  • "themeable"
    • NOT OK for HOSTED, only available to CERTIFIED apps.
    • Needed for easily change the app theme (unused at the moment)
  • "device-storage:pictures" & "device-storage:videos" (read-write access)
    • NOT OK for HOSTED: only available to PRIVILEGED apps.
    • OK for TRUSTED, as permissions access is the same as for PRIVILEGED.
    • Used for accessing the storage to keep the created media files.
  • "settings - readonly"
    • NOT OK for HOSTED, only available to CERTIFIED apps.
    • Required for:
      • 1. Check the current sound settings to play a sound when taking a photo.
      • 2. Check the device's hardware for specific zoom options on Nexus device.
      • 3. Check for changes on storage volume to updated the file destination.
  • "camera"
    • NOT OK for HOSTED: only available to PRIVILEGED apps.
    • OK for TRUSTED, as permissions access is the same as for PRIVILEGED.
    • Needed for access to the device's cameras.
  • "geolocation"
    • OK for HOSTED apps
    • Used for geotag the media captured.
  • "audio-channel-notification"
    • NOT OK for HOSTED: only available to PRIVILEGED apps.
    • OK for TRUSTED, as permissions access is the same as for PRIVILEGED.
    • Needed to show a notification on status bar when the camera is in use (e.g. video recording)
  • "audio-channel-content"
    • OK, This permission allows hosted content without any special prompt.
    • It’s used for playing sound on the app
  • "feature-detection"
    • NOT OK for HOSTED: only available to CERTIFIED apps.
    • Not used at the moment, seems like old code.

How can we make Camera a hosted app?

Lets focus on the APIs not open to hosted content yet:

  • Themeable: Does not seem like a essential feature for the application functionality so this can be disabled without impacting end-user in the short term.
    • In the longer term, it does not seem like a dangerous feature to be used by hosted app that want to use the device theme.
  • Settings:
    • Sound Enabled detection has been disabled for the moment, but in the future AudioChannelManager will take care of it [1]
    • Hardware detection has been disabled for the experiment, but the hack should be getting rid of in the future, as it is device specific.
    • Storage change detection has been also disabled for the demo, but it needs to be handled in some way if we want to keep the app usable.
  • Feature Detection
    • It doesn't seem to be used at the moment, so removing it is a good solution.

In conclusion:

  • Think about how the themeable capability could be used by any app willing to be “themed”.
    • For this experiment, we decided to disable this feature, as it does not have an impact for the user at the moment.
  • Remove the "feature-detection" permission as it is no longer needed
  • There is just one APIs that is not exposed to hosted content and that could reduce the functionality of the FM Radio Hosted App: Settings.
    • Sound detection will be handled by the AudioChannelManager on the future.
    • Hardware detection should be removed and the device specific hack should be fixed in a different way.
    • Storage changes detection is the big problem in here, with no other approach at the moment. This could be handled by opening the settings API for readonly needs, or more granularity on the permissions. (Discussions going on in https://groups.google.com/forum/#!topic/mozilla.dev.b2g/G2opSeeUYD0)

An example of the possible temporary hosted app following this approach is available at: https://github.com/telefonicaid/gaia/tree/hosted-web/apps/camera

FM Radio Application

Radio app is declaring the following permissions in its Manifest:

  • "fmradio"
    • OK, this permission allows hosted content without any special prompt.
    • It's used for accessing the radio interface, turning it on/off and tune stations.
  • "audio-channel-content"
    • OK, This permission allows hosted content without any special prompt.
    • It’s used for playing sound on the app
  • "speaker-control"
    • NOT OK for HOSTED: only available to PRIVILEGED apps.
    • OK for TRUSTED, as permissions access is the same as for PRIVILEGED.
    • Allows the app to use the device speaker for playing sound.
  • "themeable"
    • NOT OK for HOSTED, only available to CERTIFIED apps.
  • "settings - readonly"
    • NOT OK for HOSTED, only available to CERTIFIED apps.
    • Required for:
      • 1. checking changes in AirplaneMode (antenna is disabled when device is on airplane mode)
      • 2. receive a notification on attention screen showing (when receiving a call) to stop the radio playing without any delay.

How can we make FM Radio a hosted app?

Lets focus on the APIs not open to hosted content yet:

  • Speaker-Control: though it is ok for using in Trusted apps, it might be possible to open the permission for all the hosted apps too, showing a prompt warning the user about the use of the speaker. At first sight, it doesn't seem like a security risk, but more as an annoyance to the user if used maliciously.
  • Themeable: Does not seem like a essential feature for the application functionality so this can be disabled without impacting end-user in the short term.
    • In the longer term, it does not seem like a dangerous feature to be used by hosted app that want to use the device theme.
  • Settings:
    • For the airplane mode: currently there's no way to avoid the settings check, so we use a hack in the builds for allowing access for Trusted apps to the permission. We did, instead, a change on the granularity of settings request, giving access only to the specific flag needed, and not to the whole settings object [settings:airplaneMode.enabled]
    • Attention Screen: we used a different approach for this hack [2], but it seems that the solution for this will be in the new AudioChannels competing policy [3]

In conclusion:

  • Think about how the themeable capability could be used by any app willing to be “themed”.
    • For this experiment, we decided to disable this feature, as it does not have an impact for the user at the moment.
  • There is just one APIs that is not exposed to hosted content and that could reduce the functionality of the FM Radio Hosted App: Settings.
    • Stopping the radio as soon as the device receives an incoming call will be fixed with a new policy for AudioChannels in the near future.
    • To detect changes in Airplane mode, we are modifying the existing permission table for this experiment, but we should explore if there is any way to add more granularity to the permissions API, or any other way of exposing read-only settings to hosted apps. (Discussions going on in https://groups.google.com/forum/#!topic/mozilla.dev.b2g/G2opSeeUYD0)

An example of the possible temporary hosted app following this approach is available at: https://github.com/telefonicaid/gaia/tree/hosted-web/apps/fm

Clock Application

Clock app is declaring the following permissions in its Manifest:

  • "alarms"
    • OK, this permission allows hosted content without any special prompt.
    • It's used for defining alarms.
  • "audio-alarm-content"
    • NOT OK for HOSTED: only available to PRIVILEGED apps.
    • It’s used for playing alarms sound on the app
  • "attention"
    • NOT OK for HOSTED, only available to CERTIFIED apps.
    • It's used for display an attention window when an alarm is fired.
  • "themeable"
    • NOT OK for HOSTED, only available to CERTIFIED apps.
  • "settings - readwrite"
    • NOT OK for HOSTED, only available to CERTIFIED apps.
    • Required for:
      • 1. set the audio volume of the alarms
      • 2. set a flag to notify the system that there is alarms enabled.

How can we make Clock a hosted app?

Lets focus on the APIs not open to hosted content yet:

  • audio-alarm-channel: though it is ok for using in Trusted apps, it might be possible to open the permission for all the hosted apps too, however we should notify the user showing a prompt perhaps, because the apps that use this permission will be able to play sound in a high priority channel. At first sight, it doesn't seem like a security risk, but more as an annoyance to the user if used maliciously.
  • Themeable: Does not seem like a essential feature for the application functionality so this can be disabled without impacting end-user in the short term.
    • In the longer term, it does not seem like a dangerous feature to be used by hosted app that want to use the device theme.
  • Settings:
    • For the audio volume and alarms enabled: currently there's no way to avoid the settings check, so we use a hack in the builds for allowing access for Trusted apps to the permission. We did, instead, a change on the granularity of settings request, giving access only to the specific flag needed, and not to the whole settings object [settings:audio.volume.alarm], [settings:alarm.enable]
    • Attention Screen: we should use another type of screen when an alarm is fired or if this permission is not allowed in Trusted apps, we should hack it by bringing the app to the foreground and using window.open instead of creating the attention window.

In conclusion:

  • Think about how the themeable capability could be used by any app willing to be “themed”.
    • For this experiment, we decided to disable this feature, as it does not have an impact for the user at the moment.
  • There is just one APIs that is not exposed to hosted content and that could reduce the functionality of the Clock Hosted App: Settings.
    • To detect if there is any alarm enable and to set up the audio volume.
  • Also we have an issue with the audio-alarm-channel that cannot be accessed by non privileged apps.

An example of the possible temporary hosted app following this approach is available at: https://github.com/telefonicaid/gaia/tree/hosted-web/apps/clock

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/B2G/PermissionReview&oldid=1065426"