I won't be able to make the call, but I've left one comment inline: On Tue, Mar 6, 2012 at 10:15 PM, ptheriault <ptheria...@mozilla.com> wrote: > Chris, > > Below is a summary of threats and controls for further discussion. > Disclaimer: this is my understanding from various conversations, wiki pages, > bugs and IRC chats, so it's rough, probably varies from whats implemented (or > what the final goals are), but its a starting point. Ultimately the aim is a > considered security model with security controls commensurate to the threats > posed, but to start with I want to start a discussion regarding what threats > have been considered so far in the project, and the current thoughts around > what controls are in place or planned. I know that a lot of the things below > have already been considered in the project prior to me coming on board so > the main aim for me is to run through the state of things, and start > capturing the B2G security model. > > Firstly I wanted to document some assumptions: > > - All B2G applications will be Web Apps - there is no such thing as native > applications. Some web apps may be treated differently though based on > security characteristics (e.g. Came shipped with the phone, loaded from > trusted location, local access only, served over SSL only etc) > - B2G will ship with a number of included Web Apps (Gaia) to handle all the > tasks of running the device. These could potentially be replaced by the user > with alternatives > - Web APIs will provide access to Web Apps so they can perform their desired > role. E.g. An app acting as a Dialer will need access to the Web Telephony > API, in order to to make telephone calls > - Access to sensitive APIs will be controlled by permissions > > Threats Summary > ============= > In order to discuss the security measures built into B2G, we need to discuss > the threats posed.The following is a high level list of threats for further > discussion: > > - Platform Vulnerabilities > - Exploit gives control of content process > - Attack against other processes (media server, rild etc)? > - Malicious Web App > - User tricked installing malicious application > - Legitimate app is compromised at the network layer > - Compromised web app server for Web Apps hosted remotely > - Vulnerable Web App > - Web application security threats (XSS, SQLi, etc)
^^^ One way to address this threat is to require that B2G apps have a Content-Security-Policy that meets some minimum bar. Chrome has started doing this with its extensions and packaged apps (see <http://blog.chromium.org/2012/02/more-secure-extensions-by-default.html>). You might want to do something similar. Adam > - Framework weaknesses (same-origin bypass, privilege escalation, > abuse communication between apps?) > - Lost device > - User data compromised > > Controls Summary > ============= > In response to the above threats, what controls to we want to consider? The > following controls have come up in various discussions. There are probably > other controls to be discussed/raised/captured as well. > > - Low-privileged processes and process sandboxing > - Web Apps will run in low-privileged process? How is this implemented? > - Segregation between less trusted and more trusted Web App > - What about other processes (media server, rild, etc) > - Hardening of the underlying OS > - I've not seen any mention of this, but it has come up in security > discussions. > - Segregation between Web Apps > - Separate by domain, other restrictions? > - Restriction for Apps trusted with sensitive permissions > - local-only sandbox, network-only sandbox etc > - restrict cross-domain communication etc > - load only over SSL > - load only from trusted developer > - load once, then cache. Drop permissions if app changes (or prevent > from changing without update workflow) > - Restricting permissions and protection against privilege escalation > - Security restrictions for special Web App cases > - browser app (<iframe browser>, other cases?) > - permissions manager > - others? > - Data Protection > - Encryption > - Login > > Discussion is 5pm (PST) tomorrow (7th) using same phone conference as b2g > meeting. > > Cheers, > > Paul > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
