Security/B2G/FirefoxOSCommsHardening
Contents
Hardening communication protocols in Firefox OS
The success of Sandboxing child processes as a security mitigation is in a large part contingent on hardening the communications protocols between the content processes (childs) and b2g process (parent). This document attempts to describe secure inter-process communication patterns for Gecko.
Overview
Content processes (childs)
- Relatively safe when the attacker finds a vulnerability (it’s a very low rights process).
- Treat as untrusted.
- Consider compromised: what is the worst thing an compromised process could do?.
- Good place to run code logic.
- No resource access. No exceptions.
- No permissions checking.
- Sandbox only allows talking through pre-opened resources and to the IPC.
- No direct file system access (open(), access(), etc.).
- No direct socket access (bind(), listen(), etc.)
- See gecko/security/sandbox/seccomp_filter.h for the whitelist.
B2g process (parent)
- Validate inputs (from content processes).
- Sanitize outputs (before passing data to content processes).
- Does permission checking before passing resources.
- Access resources, passes them to the content process (after sanitization).
- More trusted than the content processes, but should not be trusted with everything.
Communication mechanisms between processes
There are various IPC mechanisms for the content processes to talk to the b2g process, such as IPDL, MessageManager (it’s on top of IPDL), others.
General sanitization/validation guidelines
- Validation of security properties must be done in the b2g process
- Minimize the attack surface
- Minimise the number of parameters - don’t send unnecessary data from the content process, that the b2g process already knows (i.e. use trusted data where possible rather than accepting data from the content process).
- Never send the application ID (appid) - content processes should never send the ‘appid’ to the b2g process to identify itself, since the b2g process knows which app it is talking to.
- Messages should be associated with a given permission level, so that the b2g process can perform a permission check per message. (e.g. bug 821591 since one message is used for Contacts API parent does not effectively enforce permissions)
- Consider what a content process could do by:
- spoofing messages
- replacing or omitting parameters in the message
- sending messages out of order, or omitting messages altogether
IPDL
Use simple types where possible - this takes care of most of validation (at least syntactic)
- https://developer.mozilla.org/en-US/docs/IPDL/Tutorial#Parameters_
- https://developer.mozilla.org/en-US/docs/IPDL/Type_Serialization
Message Manager
Bug 777188 - Tracking: Audit usage of "parentprocessmessagemanager" Bug 776825 - Separate message managers into senders and broadcasters Bug 776834 - Tracking: Apply security checks to sensitive DOM APIs Bug 776652 - Tracking: Apply appropriate security checks for sensitive IPDL protocols
Common errors
Content processes make security checks that belong in the b2g process (i.e. trusting the data from the content process - don’t do it!) Assumption of order of messages in the parent (what happens if child can send messages out of order)
Sending and broadcast - how does registration work?
Resource Access
The sandbox deliberately prevents access to system resources such as files, sockets etc. Ideally as much processing of resources is done in child processes though, to allow the system scheduler correctly throttle on a process level. The ideal pattern for APIs needing to access files etc is:
Files
Use separate files on a per origin basis When a child process requests a file, perform a security check in the parent to determine whether or not the child is allowed access to the file, and what access is appropriate (read, write, append etc) Open the file in the parent, but pass the file descriptor to the child for loading and processing
Others
sockets, d-bus, other?
