Hi Paul, Thanks for aggregating such a huge analysis. I would like to add more information about the unclassified "presentation-device-manage" permission.
The API that depends on "presentation-device-manage" permission allows to obtain the list of available devices that can be used as external display in your home environment, so we want to make it certified-only because it contains users' privacy information. Best Regards, Shih-Chiang Chien Mozilla Taiwan On Mon, Feb 9, 2015 at 7:41 PM, Paul Theriault <[email protected]> wrote: > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
