Security/Reviews/SettingsAPI

Please use "Edit with form" above to edit this page.

Item Reviewed

Settings API
Target	Full Query ID Summary Priority Status 678695 Settings API -- RESOLVED 750992 [Security Review] Settings API P2 RESOLVED 2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

{{#set:SecReview name=Settings API

|SecReview target=

Full Query

ID	Summary	Priority	Status
678695	Settings API	--	RESOLVED
750992	[Security Review] Settings API	P2	RESOLVED

2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

• a way to store system wide settings to a backend database
  • set:get for settings
  • Listen for changes
• Only certified apps have to settings API
  • only certified apps can *write*
• Mainly it will only the Settings API
• List of settings:
  • https://etherpad.mozilla.org/LuzVJ1iGuO
• Might expose specific settings to untrusted/trusted applications, for them to read them.
• Currently there are two permisions settings:
  • read settings
  • write settings
• Design might be:
  • App would declare in the manifest, what settings it would want access to, based on the type of app
  • Only certified apps could set them
    • I think we should allow some settings to be settable by trusted app
• Other apps could only read them

What solutions/approaches were considered other than the proposed solution?

• indexdb - this is per app rather than global

Why was this solution chosen?

• effectively a shared database
• add a layer of control for permissions

Any security threats already considered in the design and why?

`

Threat Brainstorming

• What security model has been implemented for the settings API?
  • The current implementation is similar to the SMS API and has a readonly and readwrite permission flag per principal.URI.

• Certified app vulnerability would have access to read or change any setting
  • Could be an explicit permission for read/write settings (or even an explicit subset of settings). I.e. the list of settings that the app has access to would be enumerated in manifest.
  • Even certified apps should be limited to the settings explicitly listed in its manifest -- improves auditability and a line of defense against compromised apps.
• (future threat?) Untrusted app reading sensitive data from a setting
  • Expose only a subset of settings for untrusted app
  • Review security & privacy implications of settings prior to exposing settings

* Denial of service - change a setting which breaks a feature (e.g. change RIL settings to stop phone functionality working)
** Mitigation: only certified apps can change settings
** Testing a certified app should include review of what settings it changes

• Storing some passwords in this settings database
  • Settings are currently stored in plaintext encoded format
  • No plan for a keystore at the moment
• [future threat] If we expose reading/setting to untrusted/trusted app, we should make sure, those app will not be able to reach settings they should not be able to reach. Given that it is a DB in the backend.

{{#set: SecReview feature goal=* a way to store system wide settings to a backend database

• • set:get for settings
  • Listen for changes
• Only certified apps have to settings API
  • only certified apps can *write*
• Mainly it will only the Settings API
• List of settings:
  • https://etherpad.mozilla.org/LuzVJ1iGuO
• Might expose specific settings to untrusted/trusted applications, for them to read them.
• Currently there are two permisions settings:
  • read settings
  • write settings
• Design might be:
  • App would declare in the manifest, what settings it would want access to, based on the type of app
  • Only certified apps could set them
    • I think we should allow some settings to be settable by trusted app
• Other apps could only read them

|SecReview alt solutions=* indexdb - this is per app rather than global |SecReview solution chosen=* effectively a shared database

• add a layer of control for permissions

|SecReview threats considered=' |SecReview threat brainstorming=* What security model has been implemented for the settings API?

• • The current implementation is similar to the SMS API and has a readonly and readwrite permission flag per principal.URI.

• Certified app vulnerability would have access to read or change any setting
  • Could be an explicit permission for read/write settings (or even an explicit subset of settings). I.e. the list of settings that the app has access to would be enumerated in manifest.
  • Even certified apps should be limited to the settings explicitly listed in its manifest -- improves auditability and a line of defense against compromised apps.
• (future threat?) Untrusted app reading sensitive data from a setting
  • Expose only a subset of settings for untrusted app
  • Review security & privacy implications of settings prior to exposing settings

* Denial of service - change a setting which breaks a feature (e.g. change RIL settings to stop phone functionality working)
** Mitigation: only certified apps can change settings
** Testing a certified app should include review of what settings it changes

• Storing some passwords in this settings database
  • Settings are currently stored in plaintext encoded format
  • No plan for a keystore at the moment
• [future threat] If we expose reading/setting to untrusted/trusted app, we should make sure, those app will not be able to reach settings they should not be able to reach. Given that it is a DB in the backend.

}}

Action Items

Action Item Status	In Progress
Release Target	`
Action Items
* Who :: What :: By when (Keep in mind all these things will be bugs that block the reivew bug, that blocks the feature bug) jonas :: cjones/gal Do we want to expose anything at all right now to the web? jonas :: Ask the B2G team (consumers of the API) what settings they need to read (and store?) pauljt :: Code review (both of the settings API and the consumers) pauljt :: Make certified apps specify which settings

{{#set:|SecReview action item status=In Progress

|Feature version=` |SecReview action items=* Who :: What :: By when (Keep in mind all these things will be bugs that block the reivew bug, that blocks the feature bug)

• jonas :: cjones/gal Do we want to expose anything at all right now to the web?
• jonas :: Ask the B2G team (consumers of the API) what settings they need to read (and store?)
• pauljt :: Code review (both of the settings API and the consumers)
• pauljt :: Make certified apps specify which settings

}}