1034297 - Document security 'policy' on privileged chrome api access in the child via message manager

Status: NEW

(Core :: IPC, defect, P3)

Description

[Jim Mathies [:jimm]]

Document the rules when adding a new mm api accessible in the child that invokes privileged functionality in the parent. This came out of some discussions about what we should and should not allow in the child when developing e10s desktop and for addon developers. 

The general guidelines we have thus far are: "be careful", "don't trust the child's data since it might be compromised", and "gate data writes through ui". (We currently don't gate data reads.) Also avoid generic apis that allow the child to access data the api was not intended to access. For example when providing the child with the ability to write  pref, use an api specific to that pref vs. a general purpose api that can access all prefs.

We may want to write additional docs related to ipc channels available though objects like TabParent/TabChild.

Comment 1

[Paul Theriault [:pauljt] (no longer reading bugmail)]

We started a higher level IPC hardening document which covers some of this here: 

https://wiki.mozilla.org/Security/B2G/FirefoxOSCommsHardening

Some further suggestions out of security reviews for Firefox OS:

- enforce permissions in the parent (including access levels, e.g. write vs read and other related security decisions)
- reduce attack surface: minimise the parameters sent from the child to parent
- validate in the child for performance/simplicity, validate in the parent for security
- Further to your "don't trust the child's data" point, some specific examples:
  - never allow the page/app to identify itself (don't trust origin,principal,appid etc from child)
  - never allow child data to control execution flow (e.g. bug 966141), e.g. eval, this[data]

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information