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 ne w 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.) -Jim Straus
On Mar 11, 2012, at 7:46 PM, Jonas Sicking wrote: > On Sat, Mar 10, 2012 at 1:00 PM, Jim Straus <[email protected]> wrote: >> Jonas, Paul, etc. - >> For any app, but in particular, a third party hosted apps, we could require >> that the manifest contain a signed cryptographic hash of the core of the >> application (javascript, html, css?), along with the signature of the >> trusted store. This hash would be validated as signed by a trusted source >> (like or the same as SSL certs) and that the applications core matches the >> hash. This would require that the browser/device pre-load the given >> content, but hopefully apps will be using the local-cache mechanism, so this >> should not be burdensome. Using this, once a trusted store has validate an >> application, the application can't be changed, even if it is hosted by a >> third party. We would have to enforce that a signed application can't >> download untrusted javascript (eval becomes a sensitive API?). This would >> allow a third party to host the apps approved by a given store. It would >> also prevent a hacked store site from distributing hacked apps (well, things >> like images could still be hacked, but not functionally) as long as the hacker doesn't have access to the signing system (which should clearly not be on a public machine). This doesn't prevent a hacker from gaining access to information communicated bak to a server, but at least makes sure that it isn't re-directed somewhere else. > > It's not entirely clear what problem it is that you are trying to > solve? Are you trying to avoid relying on SSL for safe delivery? Or > trying to provide the ability for stores to do code verification > before the grant apps access to sensitive APIs while still letting > those apps be hosted outside of the store? > > I don't see a problem with relying on SSL. It's a technology that > developers understand very well and which we should IMHO encourage > more (especially in combination with SPDY). > > I'm not a big believer in code signing. It's much too easy to miss > something in a big codebase and JS certainly doesn't lend itself well > to static analysis (which is what code review really is), neither by > humans or computers. Additionally one of the big benefits of the web > is the ease of deploying new code, which would be significantly > hampered if developers had to get any new version reviewed by stores. > > So I'd prefer to push back against code reviews as much as we can. If > we end up needing it, then something like what you are describing > might be a possible solution. > >> The signing mechanism can also be used to black list an app. If Mozilla >> maintains a site with a list of blacklisted signatures and devices query >> that site, the apps could be disabled. In whatever UI we have to view the >> list of apps and control their permissions, a blacklisted app would show up >> as black listed and all permissions denied. A user, who needs the app would >> then explicitly re-enable it and re-add permissions (making it a pain to go >> through the process of looking at the permissions and enabling them), along >> with suitable warnings when they do so. Probably the black list site should >> contain both the signatures to deny and an explanation of why, (consumes >> excess resources, connects to high-cost SMS servers, leaks contacts, etc.) >> so that the user can make an informed choice such as to allow an app that >> consumes excess resources, but not allow an app that leaks personal >> information or incurs excessive costs. > > I think black-listing would be more effectively done by black listing > a origin (scheme+host+port), rather than by signature. Working around > a blacklist that is by signature is easy enough that I'd be worried > people would even do it by mistake. > > But I like your ideas about including a description when black > listing, as well as (probably optionally) disabling an apps all > elevated privileges. In fact, I think one of our blacklist options > should be to let an app keep running, but disable a specific elevated > privilege. So for example a game which works great but ends up sharing > high scores over SMS a bit too much should still be able to run, but > have the SMS capability disabled. > > / Jonas _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
