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




4 years ago
2 years ago


(Reporter: jimm, Unassigned)



Firefox Tracking Flags





4 years ago
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.
tracking-e10s: ? → +
We started a higher level IPC hardening document which covers some of this here:

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]
See Also: → bug 777602, bug 820202
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.