Re: Runtime and Security Model for Web Applications

On 07/01/13 10:25, John Lyle wrote:
> On 04/01/13 19:51, Mounir Lamouri wrote:
>> >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.

I would still be interested to see how much bandwidth we would save by
requesting an "update-manifest" (or "mini-manifest" as Firefox OS folks
call it).

>>> * 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.

That is what we (at Mozilla) would call a "web application" or
"installed web application". Web Application is indeed a confusing name
but I find System Application as much confusing because that makes me
think of system-related applications like Settings, Phone, Messaging, etc..

> 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.

Sure. However, we only make a distinction between installed and
non-installed applications regarding API access for security reasons.
In other words, we are giving more privileges to an installed
applications because the user, by installing it, marked it as trustable
and we know that we can allow it to do some stuff that non-installed
applications are somewhat restricted to do (like change the screen
orientation or go fullscreen that requires user input for regular web
content).

> 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'?

Ideally, hosted and packaged applications should have the same rights.
The only difference is whether the application is privileged/trusted.
That status might open the door to new APIs that could easily be abused
if they happen to be in the hands of the wrong persons.
Exactly like not installed and installed web applications: it is only a
matter of how much the application is trustable. If someone did review
the application and put it's seal to say that it is safe and we trust
that person, we can likely allow the application to do some stuff that
the common application should not.

Ideally, we should design API in a way that prevents them to be abused
so we can allow more content to have access to them. However, some APIs,
have, by design, limitations that require them to be put in the hands of
the most trustable developers.

> 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.

For the user perspective, there is no difference in the install process
between a hosted and a packaged application.

This specification only defines what makes an application
trusted/privileged. It should not define what difference that makes. I
think that should mostly be implementation details (part of the security
story of each UA). However, if that happens to be an issue regarding
interoperability, that should be defined in specifications that apply
the limitations, not in this one.

>>> * 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.

I guess not being a native English speakers makes it hard to understand
why people hate so much the word 'trust'. I will change that to
'privileged' later, I guess.

>>> * 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.

I think having a "Security Design" section in the document would be
better than having another document. Feel free to send pull requests to
my sysapps repo :)

Cheers,
--
Mounir

Received on Monday, 7 January 2013 18:27:13 UTC