Re: Runtime and Security Model for Web Applications

On 07/01/13 18:26, Mounir Lamouri wrote:
>> 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..

Yes, there is a terminology problem.  The term "web application" is 
already used to effectively mean "website" (e.g., by OWASP) and "system 
application" could mean anything.  FWIW, the usecases discussed in this 
mailing list have been pretty diverse - I collected them (as well as few 
others from related projects) on the wiki - and they include dialers, 
contacts apps, newspaper readers, text editors... many things that might 
fit both or neither descriptions.  More would be helpful, though.

http://www.w3.org/wiki/System_Applications_WG:_Security_Model#Use_Cases_.28list_of_links.29

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

Absolutely - installation is a significant aspect of the security 
model.  Garfinkel has "install before execute" as one of his patterns 
for secure system design [1], and the absence of such a process on the 
web is (arguably) a problem now that websites are active rather than 
passive.In my opinion, and in webinos, installation should be a 
pre-requisite to using an application with access to privileged APIs 
such as Telephony.


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

I disagree - hosted applications have a completely different security 
model and therefore shouldn't be able to access the APIs that *require* 
a greater confidence in the application. Otherwise  privileged APIs are 
being exposed to the whole gamut of attacks present on the web today.  
The only way to sensibly give hosted applications access to more 
privileged APIs would be to make sure that they comply with additional 
rules, as I mentioned in the last email.


> The only difference is whether the application is privileged/trusted.

A hosted application doesn't have the same ability to be trusted as a 
packaged app.  So regardless of whether the end user (or anyone else) 
thinks they might be trustworthy, they still shouldn't be.


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

... I think we agree?  If a web application is trustable (e.g., packaged 
and signed to give it a known authenticity and execution scope) AND the 
application has been installed AND the application has been vetted by 
some party (a store, user, etc), then it might be considered 'trusted'.  
Hosted applications fail at step one.

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

Yes, and those APIs should (in many cases) be denied to hosted 
application.  Or denied to hosted applications that fail to conform to 
the security model defined in this working group, with it's additional 
requirements.  The recommendation that a particular API should not be 
made accessible to a certain class of web application should absolutely 
be made as part of this working group, in my opinion.

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


While I agree in theory, in practice I think that's a bit weak.  I think 
that the specification should define exactly the implications of 
trusting each type of web application, because they will be different, 
and then recommend what the implications are for users, developers and 
other stakeholders and how the residual risks should be handled.  I 
think it would be irresponsible not to at least _recommend_ a sensible 
default security policy in this sense.


>
>>>> * 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 :)
>

I'd be happy to collaborate on that.  As soon as I get my head around 
your proposal fully.

Best wishes,

John

[1] Garfinkel, S. "Design Principles and Patterns for Computer Systems 
that are Simultaneously Secure and Usable", Phd Thesis, Chapter 10, 
P343. http://simson.net/thesis/dpat.pdf

Received on Tuesday, 8 January 2013 15:04:07 UTC