On Sat, Mar 10, 2012 at 9:00 PM, Jim Straus <jstr...@mozilla.com> 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.
that's standard practice as part of e.g. debian package distribution management, which is why i mentioned it as an example of infrastructure to copy (verbatim) or "draw inspiration from". > 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 is also again part of the same standard practice followed by e.g. debian for 15+ years. > This would require that the browser/device pre-load the given content, that would be inadviseable. i would recommend following verbatim the practice deployed by e.g. debian package management. package information is stored separately. in fact, i'd _actually_ just recommend that B2G just... adopt the debian packaging system, period. it works, it's proven, it does the job, you don't need to arse about, and the tools for actually creating packages _and_ the tools for managing the uploading of packages are all well-established. so far, as best that people have described the requirements so far (not that there has been a formal document describing what they are, hint hint bloody well write one *grumble* :) there's nothing in the requirements for a B2G app store that are *any* different from that which the debian packaging and distribution system already provides.... perfectly. you would also have the strong advantage that OS quotes firmware quotes upgrades would be a matter of just doing "apt-get dist-upgrade". reeaaall simple. > 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?). *eyebrows raised*. interesting. you're the first person to raise this as an issue within this thread. normally i _would_ say "if i was the lead developer of this project i would be advising people to add this to the relevant section of the wiki" but have received no response as to where that wiki page is, whether anyone's taking responsibility for that task etc. etc. so... *shrugs*. ok, so, meta-comment: at this point, you've switched over from "discussion of app distribution" and have switched modes to "discussion of enforcement of permissions". > This would allow a third party to host the apps approved by a given store. unf? ok, right, right. we're back to "discussion of app distribution" mode. again: debian shows the way forward: you're referring conceptually to debian "mirrors". as the mirrors store digitally-signed apps which were centrally signed.... yyup, you got it. > 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). correct. again, here, you really need to talk to the debian people as to how they go about doing this. some of them have created some severely paranoid stuff, including i believe requiring that the master keys be crytographically distributed across N of M people. so yes, even if the quotes master quotes distribution site is compromised it still doesn't matter because the apps are actually double-signed. first signature is by the app "maintainer" (which requires that they register _as_ a maintainer and join the debian GPG ring-of-trust). second signature is by the FTP masters. packages that are not signed by the maintainer are REJECTED by the ftp upload site, period. etc. etc. so i really wasn't kidding when i said that this stuff has already been solved, done, working for 15+ years and you have about 1,000 people that you can call on to ask "how do we do this, really?" > 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. > The signing mechanism can also be used to black list an app. ok, that's something that debian *doesn't* have [explicitly]. this should be added to that non-existent wiki which is non-existently documenting the functional analysis from which the requirements specification needs to be written and formally reviewed. but, *thinks*.... ok, i know: you just create an updated package with a revision number one higher than the rejected app, and you enable auto-update. job done. package gone. > 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. to be honest it would be best to just create an override package and have it replaced. if the replacement package contains "no files", it's effectively "blacklisted". > 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. well, if the replacement application (one higher revision number) has those ACLs etc. then heck it's all good, right? if it's _really_ serious you put a package (with one higher revision number) which has zero files in it (and maybe a README / notice saying why and what happened). this is all really good stuff, jim. but i have to reiterate: WHERE IS IT BEING FORMALLY DOCUMENTED? please don't say "in the mailing list". l. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
