> Anything that is granted permissions needs to be the same thing every time.
I think we're going down a really dangerous path with this thinking. It's one thing to say that our super-trusted apps, like the dialer, should be locked down and have every bit of code signed. But in my view, the vast majority of apps -- and any app you're going to download from a store -- should have *exactly the same security model as we apply to websites*. The whole point of our platform is that it's easy for web developers to make an app, given an existing webpage. And one of the key selling points of the web is that it's easy to change your code. Let's not shoot ourselves in the foot adding draconian requirements to these 99% of apps which don't need any added protection. It's not even clear at this point that you'll be able to replace the super-privileged apps via an app store, so I think this whole thread of discussion should be dropped until such a time as we have a super-privileged app we want to allow users to replace. On Fri, Mar 16, 2012 at 5:45 PM, Jim Straus <[email protected]> wrote: > Ok, I think this has been said already, but I'm going go further... > > Anything that is granted permissions needs to be the same thing every time. > If the thing changes, it needs to have all it's permissions reset or whoever > is saying to grant the permissions needs to provide a new signature to > authorize permissions. Otherwise why bother to have permissions. I'll go a > bit further and say that is true for user granted permissions, though in that > case,the signature can be generated in the browser/gecko itself. Thus, if I > authorize some javascript (coming from some web site) to use geolocation, the > permissions manager needs to store a signature of that code and verify it > each time. This is different than the current system in Firefox. > > Following along this path, permissions aren't really granted to an > application as a whole, but to specific code that makes up the application. > So if other code is loaded, it would not have the same permissions . It also > means that eval() has to do the same verification (thus eval() doesn't have > to be restricted, but any code eval()ed would not inherit permissions. > > To answer Jonas, it doesn't mean that a store has to inspect all code. If > the store wants to trust code based on contractual obligations, that's fine. > But the code provided as being covered by the contract has to be signed so > that it is known to come from that developer. And yes, if a developer wants > to change their code, they will need to get it re-signed if they want it to > have any permissions pre-granted. If they don't mind having the user > manually grant permissions (through a dialog or the Permissions Manager app) > then they don't need to bother the store. But the next time they change > their code, the user will have to re-grant the permissions. > > On Mar 16, 2012, at 3:39 PM, Jonas Sicking wrote: > >> On Sun, Mar 11, 2012 at 6:51 PM, Jim Straus <[email protected]> wrote: >>> Hello Jonas - >>> The problem I'm trying to solve is knowing that the app I think I'm >>> getting is the app that I'm getting. SSL doesn't do anything to solve >>> this, it just protects the privacy on the wire, not what is actually going >>> through it. If a store wants to assign elevated permissions of any sort, >>> I want assurance that the app they are providing the elevated permissions >>> to is the app that I'm getting. It does't matter if the store is >>> validating the app by hand inspecting code, doing some automated >>> inspection, contractual obligations, the word of the developer, whatever. >>> If they are asserting that the application is to be trusted with any >>> elevated permissions, I don't want to get something else. Code signing >>> doesn't tell me what an app does, just that it is the app hasn't been >>> modified. Either through a developer changing their application, a hacker >>> breaking into a site, or anything else. If the developer does want to >>> update their app, I want to the store to re-assert that the > new app should be able allowed to have whatever permissions it is granting, > not just the developer doing it unilaterally. I suspect that stores will > compete partially on price and breadth of offerings, but also on their > assurances that the apps they are providing are safe. >>> Actually, in thinking about it, I think that stores that sell apps that >>> come from a third party server are more secure, not less as a hacker would >>> have to obtain the ability to sign an app and also break into the third >>> party server to affect a change. And they would have to hack into another >>> server to affect a second app. If a store hosts everything themselves, >>> hacking that single server and getting the ability to sign apps would >>> expose lots of apps to being hacked. >>> Black listing based on scheme/host/port is probably not sufficient for an >>> organization that distributes more than one application. This was raised >>> in a different discussion related to web apps in general. But even if it >>> was, we may want to blacklist a particular version of an application, not >>> the application in general. The signature provides a mechanism for this. >>> I agree that removing permissions for some application infractions might >>> be a good idea. The actual semantics of what the black list can do to to a >>> particular app can be discussed and enumerated. But there will definitely >>> be apps that we want to completely disable (eg. if we find an app is >>> hijacking information, I don't want it running at all.) >> >> I have to admit I've lost track of what it is that you're actually >> asking for. "knowing that the app I think I'm getting is the app that >> I'm getting" depends highly on the definition of "the app". >> >> As I've stated, I don't want to force app developers to have to their >> code inspected by stores, nor do I want to force stores to review >> developers code. And if a code review hasn't happened I don't see what >> signing the code buys anyone. >> >> Instead I want stores to verify that they can trust a developer >> through things like contractual means and restricting which set of >> privileges they give an app. It has also been suggested that stores >> should be able to require certain technical security measures from the >> app, like EV Certs and/or certain CSP policies. This sounds like great >> ideas to me. Likewise, it would likely be a good idea to have minimum >> requirements on stores that they use things like EV Certs and CSP >> policies. >> >> If we do this, then we can use SSL both go guarantee that the code >> that is delivered to the user is the code that the developers have >> authored, and the security policy that the store intended to entrust >> the code is the policy that is delivered to the user. >> >> / Jonas > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
