On Wed, Mar 14, 2012 at 11:02 PM, ptheriault <ptheria...@mozilla.com> wrote: > > I actually liked the idea of "more privilege for "installed" apps, less for > "remote" apps" - the number of apps that will need elevated permissions are a > very small percentage (and I think that was B2G's original plan?) . As I > understand it, Gaia apps are already static HTML apps
yes! > (i.e. it would be easier to package and sign these applications than normal > websites), correct! again, it's worth reiterating: "normal" websites have *NOTHING TO DO WITH* gaia apps. you really really really really _really_ need to stop thinking of Gaia apps as having ANYTHING to do with "web sites". yes their source code happens to be in HTML and Javascript (and if i had my way they'd be python as well *sigh* and if i _really_ had my way they'd be absolutely any programming language available under the sun. hint hint XPCOM big hint... :) but just because the source code is HTML and Javascript it DOES NOT MEAN THAT IT HAS ANYTHING TO DO WITH WEB SITES. it is quite fascinating to see people who have been working with mozilla for... N years making this same mistake :) B2G really is quite fundamentally... odd, and wonderful :) > and these would be the main apps which require critical privileges. I > suppose that developers will not want to be tied down to a static HTML model > though. well then: let's examine that case. * the static HTML as part of the package downloads dynamic HTML, stores it and runs it. the equivalent analogy is that of a debian package such as ruby using "ruby-gems", python using the zope-style package/downloader or perl using cpan. have you _any_ idea how much of a fuck-awful mess that these "debian package bypassing" mechanisms get people into?? extreme case: did you hear the ubuntu development team did? so many of them had personally installed python 2.6 into /usr that they made a fucking STUPID decision to package the *standard* python 2.6 runtime.... in /usr/local! that's such a clear violation of FHS it's just hard to imagine why they made such a clueless decision. it's particularly bad when the "vanilla" package is *different* from the debian-packaged one. this often happens with system-level packages. so, another example which really drives this home: do you recall what happened with webmin? webmin was such a fuck-up that i can no longer even find it by doing "apt-cache search webmin". webmin was self-upgradeable. but unfortunately it was also installable as a debian package. that meant that it could actually severely fuck up your system, because you could potentially upgrade it to a version which not only bypassed all the standard debian packaging (config file locations etc.) but also the "upgrade" could potentially not even be SUITED to a debian system, but could accidentally be one for REDHAT or gentoo! so it would try to overwrite config files or try to access config files that didn't exist! you see how much of a serious problem it is, by analogy, to even *contemplate* allowing people to download apps that do downloading of apps? i strongly *strongly* advise you *not* to even allow apps to save source code (HTML+javascript) of other Gaia apps onto the local filesystem for execution within B2G. just... don't do it. if you're going to allow anything, it should be temporary code. perhaps... i dunno... download something that is *only* allowed to be from certain web sites, where the URLs are displayed to the user (wildcards allowed?), and its purpose is to cache stuff. BUT, any such downloading should come with a severe warning that it could result in arbitrary code execution from a remote source. i can see why it should technically made possible, but for many many reasons it should be discouraged, and monitored carefully. that's easy enough to do because the permissions set should come up as a red flag before the app is allowed to go out to the public. anyway, summary, paul: * you very very much need to conceptually detach "Gaia apps which are HTML/JS" from "web site source code which happens to be downloaded by the Gaia B2G browser application". * the excellent point you make about dynamically allowing arbitrary download, storage and subsequent execution of HTML/JS (whether as an app or as part of the execution of an app) is a serious one that should either be blanket denied or watched very very carefully. l. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
