(allo lucas, i linked this discussion here via googlegroups: https://wiki.mozilla.org/Apps/Security#Concepts_to_be_given_Official_Definitions)
On Fri, Mar 16, 2012 at 4:27 AM, Lucas Adamski <[email protected]> wrote: > Discussion so far has illustrated the fact that we need to define what a "B2G > app" actually means at a foundational level. That means defining what an app > can consist of, the origin of those assets, and how they are delivered, > updated and stored on the device. I'd like to fork this into its own topic > to ensure it gets the focus it deserves without derailing discussion of > Jonas's proposal. *thumbs-up*. btw it'd be nice if someone could mention any alternative infrastructure that they may have heard of that does an equivalent job. i know debian, i don't know yum too well but know it's pretty much equivalent, i know openembedded's .ipk and .opk system (and its limitations) - i know microsoft's "manifests" system (and it's absolute hell on earth despite promising to solve the dll hell problem) - i know of sun's patch hell system (tried it once: completely utterly failed to comprehend it). err... that's all i know about. anyone else know of any other deliver/update/store systems, as loosely defined as that and yet still meeting those loose requirements? oh yeah - one more (which i've only heard about a couple of hours ago: "air://") > I'm not going to introduce anything novel here other than to summarize the > various points that have been made during the discussion so far, then maybe > make a stab or two at some assumptions. I'm guessing many of the > participants in this discussion have a pretty clear idea of these already, > but they all seem to differ somewhat. yeah, you're telling me :) > To keep it simple, lets assume an app contains JS, HTML, CSS, various media > assets and (maybe) a manifest. It does not contain any binary or other > inscrutable components. ok. so, linux kernel is out-of-scope for this discussion, as is anything which gives meaningful answers if you run the unix "nm" command on it. sounds sensible/sane to me. ... first observation: if you define an app as comprising "JS, HTML, CSS, various media assets and (maybe) a manifest", that's a lot more than just one single file. that would seem to imply automatically that you need "some sort of packaging of some description"... but *only* if you actually care (i.e. if the app could do something malicious). a subdirectory or a root URL also kinda qualifies (as long as there's a secure delivery mechanism associated with that remote URL) > == Types of apps == > At a high level, B2G apps fall into two or three general categories: > a1) Privileged applications that have special abilities that could cause > serious damage to the user or device if abused > a2) Normally privileged applications that look and feel like a typical device > application, but are restricted from accessing API's that could compromise > the device or the hurt the user (without explicit consent or maybe never) > a3) Web sites that want to use certain privileges > > It could be argued that a2 and a3 are largely the same thing, but they may > vary in default privileges (and maximum privileges) so I'm breaking them out > for now. ack. looks reasonable to me. > There is also the OS/kernel itself, but lets assume thats out of scope for > this particular discussion yes please. whew :) > as it warrants its own separate security discussion. yes. that can't be left out. i meant to say earlier that the name of the wiki page implicitly excludes OS/kernel/B2G-the-app/etc. from consideration, which is... bad. it can't be ignored. > == Deployment == > b1) static application package, downloaded once from a remote server and > authenticated & installed locally > b2) dynamic remote app locally launched and cached ("locamote"?), identified > by a manifest > b3) typical remote web app with no local presence, identified by a domain good definitions... comments below > == Scope == > c1) only locally installed code, authenticated by a code signature, is > considered and permitted to be part of the app. May load remote data and > assets? > c2) remote code cached locally, restricted to loading code from a specific > domain or set of domains as identified by a manifest (requires HTTPS-only for > the restriction to be meaningful) > c3) remote code cached locally, not restricted to any particular domain (does > not require HTTPS); may have manifest? (what security properties would that > provide?) > c4) remote code, no manifest and no implicit trust ditto. > == Putting it together == > > Here's where I go out on a limb and assume from the recent discussions that > we are coalescing towards three models. > > Gaia app: consists of a1, b1, c1. > A typical local app, with a static codebase that is installed once, > authenticated by a code signature and prohibited from dynamically loading > additional code. Granted signicant privileges in return. Origin of these > apps is probably restricted to a small set of app stores as defined by OS > configuration. Explicit update process. > > B2G app: a2, b2, c2 > Remotely hosted but locally cached, identified by a manifest. Appears to > user as a local app. Codebase restricted to a single origin, requires HSTS > for authentication. All code (JS, HTML CSS) must be loaded from this origin. > Explicit trust may allow some limited implicit privileges (i.e. fullscreen). > Transparent, implicit update process. Can load assets from other domains > (specifics TBD). ok, here's the thing. these are two extremely good definitions, but my take on it is that one is actually a subset of the other. once you add the concept of "apt://" or "yum://" as a URI, with all that that implies, that takes care of *both* cases. ... more or less :) devil's in the details. might be necessary to include in the URI specification the potential for expressing the full /etc/apt/sources.list line syntax (or yum equivalent) hum... have to think about that. ok, thought about it (a little). allowing the full /etc/apt/sources.list line syntax "deb http://foostore.com/b2g stable main" to be included in the URI would easily allow new domains to be added. you'd start by specifying the package name of the keyring: "apt://foostore-apt-keyring?store=http%2E%2F%2Ffoostore.com%2Fb2g&archive=stable§ion=main" something random like that, it's enough to indicate "wark wark, this is a new store, not listed, do you want to trust this store?" and to run the user through the implications of adding entirely new stores. personally don't like the syntax but you get the basic principle. > Web app: a3, b3, c4 > No manifest, no implicit trust, not cached locally (i.e. no offline mode). > Normal web content security model. No install experience. Really just a > remote site that requests certain webAPIs. yeah, i'd plump for that as a good definition. the list of webAPIs (other than the existing ones that are part of the standard W3C HTML5 spec as it stands right now) that should be allowed should, in my opinion, be either very very carefully thought through, very small, or better yet reduced to zero. then if you *really* want the (untrusted, untrustable) "normal" web app to have access to information that's available through WebAPIs, you get a B2G / Gaia app to monitor the iframe in which the data is required and "inject" the results into either the DOM of the iframe or into the iframe's global variable context (i'm not keen on that personally because python-xpcom can't gain access to the JS context, which is why we use the DOM modifying trick instead) > I'm sure I've trampled on some assumptions & use cases. neeh, i'd say it's a pretty clear assessment. i'd be interested to hear your thoughts on what adobe's doing with AIR: https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html especially their attempts to, i think.... they may be allowing something like b2, c3 and.... a2 i think it is. they mention something about restricting eval, and a bit more besides. l. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
