Re: Runtime and Security Model for Web Applications

On 04/01/13 19:51, Mounir Lamouri wrote:
> On 02/01/13 11:57, John Lyle wrote:
>> I think that the document highlights some really good areas for
>> discussion and that there is plenty of overlap with our proposal.
> ... which is a good sign, right? :)

Hi Mounir,

Absolutely! There's lots of good stuff here that fits nicely with the 
webinos security model and the requirements we suggested.

>> * 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.
> As Jonas said, JSON seemed better. It isn't really a decision made by
> this specification given that Mozilla had a Open Web App Manifest
> specification since some time already.
>
> However, that part of the specification can easily be moved to WebApps
> and change to whatever format. The rest of the specification should be
> independent of the format of the application manifest. Some rewording
> might be needed though.


Ok, that's useful to know.  The reason I asked is that (1) we're using 
widget specifications in webinos for our web applications, (2) the 
widget spec is pretty comprehensive, and (3) it would also allow for the 
reuse of the widget digital signature & widgetupdatespecifications, 
which fulfils another requirement.

But I appreciate that there are reasons for doing something else.


>> * 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.
> Jonas and I have different opinions on this. In my opinion, we should
> simply have the same manifest inside and outside the package. The only
> reason we have a manifest outside the package is because it is easier to
> check for an update if we give a manifest. In other words, if HTTP
> semantics do not apply, we can download the manifest and check if it has
> changed or check if the checksum of the package has changed (or do
> anything that sounds clever). If we had no external manifest, the only
> solution would be downloading the package and checking if there is an
> update. Otherwise, relying on some ZIP format specificities that might
> not be working very well in practice (ie. get the file table of the zip
> file and only download that and the manifest). The main concern is
> obviously to same bandwidth.
>
> >From there, having the same manifest or not doesn't really matter as
> long as the external one as the info required for it and the internal
> one has the other info. The only reason it would matter would be to save
> a few bytes. I think requiring the same manifest would make things
> easier and more reliable.


Either way, I think it makes sense to save bandwidth by havinga separate 
manifest as you mentioned.


>
>> 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?
> This sentence about genuine updates was assuming that the package is
> signed. In that case, we can trust anything inside the package.

Ok, that makes sense.


>> * 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.
> I'm not sure what you mean by "system application". A hosted application
> is an application that is related to real pages on the web using
> appcache for offline usage but getting update as a website would. Except
> for security concerns, there is no reason why those application should
> be treated differently than packaged applications.


I find this a bit confusing.

A "system application", I had assumed, is a set of web pages & resources 
that have been given access to additional JavaScript APIs - those 
defined in this working group - and because of the extra security issues 
surrounding such APIs, is also under a new security model.  At the very 
least, it ought to be explicitly installed and have some kind of 
permission-based access controlsystem.

This implies that a normal web page is not a system application, because 
it adheres to the current browser security model and does not request 
the use of these APIs.  Any web page that does requests access to these 
APIs, *must* be a system applications and, in order to be considered 
safe enough to do so, *must* be executed in a way that adheres to the 
security model being defined by your proposal.

In my opinion, a hosted application ought to have similar security 
properties to a packaged application.  It should have a manifest (to 
define least privilege & identify the author), be served over https (to 
make up for the lack of integrity & authenticity guarantees), should 
still have default CSP-based restrictions (to help protect against 
content injection threats), and so on. Otherwise, if the intent is to 
define a two-tiered security model, with 'normal' and 'privileged' apps, 
then it ought to be coupled with the implications for what a 'normal' or 
'trusted' app is able or not able to do, again with respect to the APIs 
we are defining.  Perhaps only 'privileged' apps can access the 
telephony API, for example?  And only a packaged app can be 'privileged'?

It's also not entirely clear what changes in the install process for a 
hosted versus packaged application.  Clearly updates will behave 
differently.  It might also be that hosted applications (due to their 
different security properties) aren't permitted to use certain APIs.

It could be that I'm confused by terminology, or missing some 
assumption, but it would be helpful if there is a common understanding 
of what a 'system application' is, and what the differences are between 
hosted and packaged applications with regards to the security model.


>> * 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 think 'trust' defines better how this is working than 'privileged'. As
> I see it, 'trust' is the cause and 'privileged' the consequences. We
> indeed give privileges to some applications but mostly because we trust
> the application to not do anything nasty with those privileges.
>
> As a user, if I browser a store and see that "this application is
> privileged" I will definitely be anxious regarding what they could do
> with those privileges. However, if I see "this application is trusted"
> and if I trust the store, I would think that I am safe.
>
> Anyway, this is only wording and if you think privileged is better, I
> will just change that.


I agree that trusted and privileged are not synonyms. Unfortunately, 
'trusted' is not a word with a single meaning.  To some it actually 
means 'trustworthy', to others it means 'given access to privileged 
features'.  More reasonable in this context is probably the word 
'trustable' - e.g., a trustable application is an application about 
which it is possible to make a trust decision, because the integrity, 
authenticity and scope of the application is well defined.  `trustable' 
being distinct from `trustworthy' because it does not imply review or 
oversight. However, I'd as soon avoid *any* use of the word trust.

'Privileged' is one option, depending on what this is actually supposed 
to imply (what additional privileges does a 'privileged' app have?).  
There's no obvious alternative at the moment - perhaps 'verifiable', 
'credible','strict', 'curated' ... better suggestion are needed.


>> * 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.
> It is indeed a discussion. That is why the section is marked "non
> normative".


I think the proposal would be stronger with a more rigorous and less 
discursive non-normative security considerations section.  I would be 
happy to help.  In fact, I think it might be sensible to have a 
completely separate document describing the rationale behind the 
security model, as this will explain the various security design choices 
and check for consistency against threats and known attacks.

Best wishes

John

Received on Monday, 7 January 2013 10:25:46 UTC