> > > Each API which requires some sort of elevated privileges will require > > one of these capabilities. There can be multiple APIs which > > semantically have the same security implications and thus might map to > > the same capabilities. However it should never need to be the case > > that an API requires to separate capabilities. This will keep the > > model simpler. >
This constraint might prove rather difficult to stick to. Android has a significant number of API calls with multiple permission requirements. This seems to be a natural side effect of transitivity + a large API: given methods A and B that are protected by different permissions, you will eventually create a method C that invokes both A and B. A natural way that this occurs is that you have separate "read" and "write" permissions, and then you create a new action that involves both read and write actions. > > Another thing which came up during a recent security review is that > > we'll likely want to have some technical restrictions on which sites > > can be granted some of these capabilities. For example something as > > sensitive as SMS access might require that the site uses STS (strict > > transport security) and/or EV-certs. This is also applies to the > > stores which we trust to hand out these capabilities. > I strongly second restricting certain capabilities to all-HTTPS websites. I have no reason to believe that website developers are much better than Chrome extension developers, and Chrome extension developers use HTTP resources in insecure ways all the time regardless of how privileged the extensions are. On another note: I think a permission test suite is crucial for the long-term success of the API. Every time someone defines a new API, he/she should have to build an accompanying permission check test. I don't know what Mozilla's code review model is but perhaps this process could be incorporated into it. This way, the permission policy is always known and it is always possible to verify that it has been implemented correctly. Otherwise, you end up with Android's complex-yet-undocumented permission model. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
