Security/B2G/PermissionReview

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:

• SystemXHR
• TCPUDPSocket

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.

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