Following up on the previous discussions [1] [2] I’ve been doing some analysis of the current app permission model for FxOS. This email is to start discussion around exposing APIs to web content - i.e. hosted apps and regular websites. I made some notes [3] and a table of all permissions [4] and below is a summary of observations to get the discussion started. Note the premise of this exercise was to explore what is possible to expose to websites. Im still currently of the opinion that an app signing mechanism is going to be needed, and we should improve our packaging model to be more web friendly, but I wanted to explore how far we can get without app packaging/signing. This email is long, but it basically comes down to 2 questions:
1. What APIs (or use cases) are the highest priority to expose to web content? 2. What security controls are we prepared to invest engineering resources in in order to make these APIs safe enough for web? == Approach == The web’s threat model is that content is untrusted, so existing privileged/certified APIs are too dangerous to expose to such content. APIs need to be made safer through a combination of: - only exposing safe parts of APIs - adding mitigating controls to APIs - creating more specific APIs to safely solve use cases - creating more sophisticated security UI (beyond just prompts) - mandating adoption of existing web security controls (TLS, CSP etc) == General Security Requirements == The following requirements are high level, and there are exceptions, but these are the sorts of things which currently prevent certified & privileged APIs from being more widely exposed. - Prevent access to underlying OS & data - all access must be mediated by user (e.g. file input) - Prevent direct access to local devices - access mediated by the user (e.g. navigator.getUserMedia) - Cause system instability due to resource consumption (CPU, bandwidth, disk space, battery etc) - Limit network connectivity to protect local networks (same-origin policy, port limitations etc) - Avoid fingerprinting: don’t expose unique user or device identifiers (especially permanent hardware addresses or private user data) == API Categories == In going through all of the permissions, some categories of APIs emerged, with each category having differing security control options. === Data Access === Some APIs provide direct access to local data stores, e.g. contacts, Device-Storage (pictures, video, music, sdcard). Access can be read-only or full read/write access. There are several things to consider here: * a user might grant pictures access at a time when they don’t have any private photos, but forget to revisit that decision later after taking photos that are more sensitive * access can permanently destroy data * once private data is public, no way to make it private again * if website XYZ gets hacked, the hackers gain access ALL data for ALL users, not just the data the user has uploaded to the website. Basically the user needs to understand that by granting the permission, they are effectively transferring all their data onto the app’s service. Mitigation suggestions: * silo data: e.g. put photos in albums, and allow users to only grant access to specific photos or albums. Allow users denote “public” data which can be accessed by websites, and prevent access to other data (i.e. make it clear to users that this data is available to the web) * make web APIs data safe: prevent overwrite and make delete “move to trash folder” instead so user can always recover data * Provide auditing so users can trace what app access ===Device Access=== A number of FxOS APIs are created to provide access to various hardware devices: e.g. Bluetooth, NFC, Motion Sensors, fmradio, wifi. Making these more safe depends completely on the device being accessed. Relatively safe devices like motion sensors and fmradio only pose a mild privacy risk and could perhaps be mitigated user mediation (prompts). But devices like bluetooth & nfc are significantly more complex. The W3C bluetooth group has a good enumeration of privacy & security risks [5] for exposing just BluetoothLE. The approach they have taken is to abstract away detail, and provide high level APIs which don’t have the same security risks as the low-level hardware APIs. For example, instead of exposing an API which allows control of bluetooth adaptors (like how mozBluetooth currently does) expose a service which allows connected to a remote service like “heart-rate monitor”. See [6] for an example. Thats just one example - I’ve been working with the bluetooth team to get to a point where we can expose bluetooth to privileged APIs but much more work is need to get even just bluetooth exposed to web. === Unrestricted network access === Some APIs provide local network access - e.g. SystemXHR, tcp-socket & udp-socket. These are very commonly requested APIs (in marketplace stats, but also anecdotally on list and dev meetups). The risk is that untrusted web code will access internal systems that were not intended to be exposed to the internet. There have been some suggestions around solving the single server access case, but the general case of allowing unrestricted network access is problematic. Mitigation suggestions: * request access on a single access basis. E.g. "Do you want to allow http://foo.com to make connections to http://bar.com” * enforce anonymous access (ie no cookies, no http-auth, SystemXHR already does this) === Push Events & Notifications=== Ability to receive push events, and display notifications to the user. We already provide access to “push” permission. Why is wappush more restricted? How do extend support to the web, not just web apps? (Im not familiar enough with these APIs to answer this, maybe someone else can comment). === Audio Control === Audio API (audio-channel-* & speaker-control) risks are mainly annoyance and DoS of vital telephone services. These are likely solvable using a combination of granting priority for privileged/certified applications, and also figuring out a safe way for a user to switch audio priority to foreground 3rd party apps. NB currently competing audio policy is only allowed between loop and the dialer and requires both to co-operate. We need a solution for hostile or poorly implemented apps. === SMS === SMS is risky mainly due to the cost involved. Risks include cost of sending SMS and also SMS are very sensitive - e.g. often used in 2-factor auth (e.g. banking) But there are different use cases. For example, many use cases just need the ability to receive SMS - instead of granting SMS permission, we could expose a read-only SMS datastore which other apps could observe changes on which removes the cost risk (but not the sensitive data risk). Sending an SMS is a use case available via web activity. === Telephony & Mobile === Telephony & mobileconnection seem more dangerous - not sure that there is a strong use case here? Thoughts? Do you really want websites making phone calls, locking your SIM card? === Others === Theres lots of other permissions that don’t really fall into a category but are possible. See [3] for more detail (and please feel free to comment!) Thanks for getting this far! We’ll need to dive in to a per-api basis eventually but I wanted to start from a holistic approach. Suggestions welcome. - Paul [1] Can we deprecate packaged apps? https://groups.google.com/d/msg/mozilla.dev.b2g/Cepl-i0Epn8/GsHzE-An7o4J [2] Proposal: Privileged Hosted Apps https://groups.google.com/d/msg/mozilla.dev.webapi/pCY77YAg_i4/NoDBbEziyzoJ [3] Permissions Review Notes https://docs.google.com/document/d/1Ew5xEQYD_pBKZdoU_A986au6LiRWxjVkgb72Hj3kzUA/edit?usp=sharing [4] Permissions Analysis (Nightly 2.2+ permissions, 2 Feb 2015) https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdGVpcVpuMS1meVlDNmVFRFJ1X1JPbXc#gid=0 [5]https://wiki.mozilla.org/Security/B2G/PermissionReview [6] https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy-considerations [7] https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/explainer.md _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
