Re: Runtime and Security Model for Web Applications

On 28/12/12 20:20, Mounir Lamouri wrote:
> Hi,
>
> On behalf of Mozilla, I would like to propose the following document as
> a base to work on the 'Execution Model' and the 'Security Model'
> deliverables for this Working Group's Phase 1:
> http://mounirlamouri.github.com/sysapps/proposals/RunTime-Security/Overview.html
>
>

Hi Mounir, all,

I have some comments & questions about this proposal, mostly for 
clarification.

I think that the document highlights some really good areas for 
discussion and that there is plenty of overlap with our proposal.

* The abstract should probably read "This document specifies the runtime 
and security model of _System Level_ Web Applications".
* Is there a special reason why application manifests need to be 
redefined, considering the presence of Widget packaging standards?  Is 
it just the need to define new elements, or a desire to get away from 
XML, or both?  Both of which are perfectly good reasons, I'm just 
interested to know the motivation.
* "required_features" is distinct from "permissions".  What happens when 
a permission is requested for a feature that isn't required?  Or the 
other way around?
* Is there a concept of a feature or permission that is optionally 
required? I'm thinking of situations where the device is under a 
corporate policy, for example, and a certain feature or permission can't 
be granted under any circumstance.  Can an application express that this 
feature is a deal breaker, or are all 'required' features actually optional?
* The 'version' string is not interpreted, but in the 'updates' section, 
the UA is supposed to compare version numbers.  Can you elaborate on the 
purpose of the version number?
* Where is the origin of the application defined by the app?  It isn't 
listed in the manifest properties, but referenced frequently.  In 
particular, section 3.1 lists the 'origin' as being the origin described 
in the manifest, separately from the installOrigin.
* Is it intended that the developer's website be connected, in any way, 
to the origin of the web app or manifest?  Is the developer's website 
purely given for information?
* For packaged apps there are two copies of a manifest: one outside and 
one inside.  Which has precedence?  What happens when they conflict?  
You mentioned that this is for update / installation purposes - could 
you elaborate?  It seems to me that these shouldn't both be called 
'manifest' as they serve different purposes and have different 
contents.  Does the manifest inside the package contain the 'package' 
section?  If not, it wont contain a copy of the URL of the package, 
which might be a problem for downloading updates.  How is the 
application manifest inside the package proof that the update is 
genuine?  Are you assuming that packages are served from trusted origins 
only over TLS/SSL?
* Can packaged apps load anything (images, for example) from the network?
* You don't seem to have defined 'hosted' applications, except "not a 
packaged application".  Can a system application be a hosted 
application?  This is a bit unclear.
* Applications are isolated from each other.  In some of our (webinos) 
use cases, apps need to be able to communicate with each other in a 
limited way (e.g., over a message channel).  Is this forbidden in your 
proposal?  Or can one application trigger a System Message to another 
somehow?
* What is the 'pool of messages' used for when an application has no 
message handler?  Is this in case the application defines a message 
handler subsequently, and then receives all the (old) messages?
* Permissions can be granted automatically, denied automatically, 
granted/denied by the user at install time, or granted/denied by the 
user at runtime.  Is there a file or system for saving these decisions 
and specifying defaults?  This (or at least requirements for it) seem 
like a good thing to include in a potential standard.
* The "basic Permissions" specified in 8.3 - is this list exhaustive, or 
are these only examples?  Geolocation seems an odd one to include with 
the others - in our experience, Geolocation is bit 'special'.
* I think section 8.4.1 is oversimplified.  Is there a threat model or a 
risk analysis available from B2G that we should be referring to?
* I suggest not using the terms 'trust', 'trusted', 'trusty' or similar 
in specifications because it inspires no end of confusion (see Dieter 
Gollmann's classic essay "Why Trust is Bad For Security").  If such 
words really need to be used, a definition would be helpful.
* I'm concerned that relying only on the trustworthiness of the origin 
of an application is too limited a measure.  It removes the opportunity 
for system level applications to be side-loaded (which is a *big* 
decision to make) as well as having some other limitations.  I can't 
place trust in an author, only a distributor.  It also provides no way 
for application developers to have assurance in the integrity of their 
packaged apps that are distributed by third parties.  However, as I'm 
aware this is the approach taken in Firefox extensions, i'd be 
interested to know whether you have analysed how well this has worked in 
your experiences.
* Section 8.4.4 seems to be a discussion rather than a set of security 
considerations.  I think there's a good case for a more strict set of 
security requirements, expected threats and definition of the 
relationships and reliance between different parties involved.  I would 
be very happy to collaborate on such a section.
* Section 8.4.5 - We have a broadly similar CSP policy in webinos, but 
we haven't trialled it extensively with developers yet.  Do you have any 
experience with this recommendation so far?
* Section 8.4.5 - In line with the principle of least privilege, in 
webinos we're specifying that applications must specify their 
'connect-src' in the manifest, such that applications can only connect 
using websockets / XHR to pre-defined domains. Can Packaged apps in this 
specification create XHRs to any origin?
* Section 8.4.5 - If a packaged app embeds an iframe pointing to another 
origin, what is the expected behaviour?

Many thanks,

John

Received on Wednesday, 2 January 2013 11:58:07 UTC