Suggestions for the security model deliverable

Dear all,

I'm not a member of this working group (although I'm working on it) but 
I thought I would share some of the points we've been thinking about 
regarding the security model for system applications.  Consider these a 
set of potential talking points, a thorough threat-driven security 
analysis is required.

1)Install before execute

The first difference between a browser application and a system 
application is that system applications should follow Garfinkel's [1] 
principle of "install before execute" such that only explicitly 
installed applications are ever allowed to run. It should also be clear 
on conforming platforms that using a system application always means 
'running' the application rather than viewing the content, unlike a web 
page.

2) Packaging, signingand definition

The content of a system application ought to be enumerated in some kind 
of manifest and signed to prevent tampering.  This doesn't prevent 
accessing remote content, but protects initial distribution of the 
application and the integrity of files while on a platform.

For this I would reference Jonas Sicking's post on B2G's packaged 
applications [2] as well as the well-known Widget standards

3) Restrictions on external sources

System applications should be able to access remote content, but only 
from pre-defined locations and over secure connections.  Options here 
include CSPandthe use of WARP to define which origins may be accessed.  
I may be wrong, but the two seem incompatible.  There's also the WAC [3] 
proposal of a 'recognised origin' for each system application [3].

Another question is: how should inter-application communication be 
provided?  Are there additional restrictions on channel messaging / XHR 
/ other communication mechanisms that should be enforced for system 
applications?

4) Least privilege access control

Native mobile applications have benefited from least privilege access 
control, as noted by Felt et al. [5]. It seems reasonable to state that 
system applications should also be required to express the privileges 
they will need to execute properly.

5)Interoperable access control

The platform executing a system application will want to be able to 
control what a particular application is allowed to do. For example, 
changing the system application's access to a resource based on a 
companies security policy, or data roaming considerations.  As such, 
system applications ought to have an interoperable access control 
system.  E.g., an access control policy file such as the one found in 
webinos [4] and previously in BONDI and WAC.  Other options might 
include capability tokens. This is a *vital* difference between 
browser-based and system applications.  It would allow system 
applications to appear equal to their native counterparts and be 
controlled using the same interfaces.  This may present challenges when 
trying to implement permissions based on implicit rather than explicit 
consent, and when trying to reuse APIs from a browser context.

6) Hooks for monitoring system application activity

A defence-in-depth measure for system applications would be to allow 
their activities to be monitored by other applications. For example, 
logging their access to telephony, contacts, etc. This would allow for 
indicators or policies which identify potentially malicious behaviour.  
I believe a good standard would make sure that such 'hooks' are 
possible.  This is similar to the 'sensor widgets' described by Lin et 
al. [6]

7) Restrictions on inline JavaScript and dangerous functions such as eval.

Based on Chrome's policy [7] towards extensions, it seems reasonable 
that system applications would be expected to avoid dangerous practices 
such as in-line javascript and eval() and function().  This is also 
related to the restrictions on external sources.

8) Isolation expectations

System applications should expect to be granted an isolated area of 
storage for local data, free from interference by other native or system 
applications.  They should also expect to be run in an isolated context.

9) Application lifecycle

Will system applications require a specification such as Widget Updates 
to define how they can be updated, or is this beyond the scope of this 
working group?  What about revocation, and securing the connection 
between an application and its distributor?

10) Application provenance

App Stores can be an important way to prevent malicious or badly 
implemented system applications from being installed.  From the 
perspective of this working group, I'm therefore assuming that some 
consideration will be needed for how to support app store certification 
of applications.  Examples include WAC's approach to processing widget 
signatures [8].  I'm also assuming that this will need to be very 
flexibleto not conflict with various ecosystems.

11) User interface guarantees

What guarantees will the runtime environment of a system application 
make about the presentation of UI elements to mitigate threats such as 
clickjacking?  This is an open question, as I'm not familiar with the 
relevant prior art.

12) Fingerprinting, linkability and privacy considerations

I would consider system applications to be sufficiently trusted that any 
fingerprinting concerns are out of scope. However, access to common 
device identities (such as a UDID) still seems worth considering as it 
has implications for re-identifyingusers in different contexts.


I hope this list is useful and look forward to comments.  I would be 
happy to collaborate on any other proposals that are in progress.

Best wishes,

John




[1] Chapter 10 of Simson Garfinkel's thesis 
http://simson.net/thesis/dpat.pdf .  I blogged about it here - 
http://www.cs.ox.ac.uk/blogs/sss/2012/03/23/garfinkel-design-patterns-for-the-web/
[2] 
https://groups.google.com/forum/#!topic/mozilla.dev.webapps/hnCzm2RcX5o/discussion
[3] http://specs.wacapps.net/core/#security-and-privacy
[4] http://webinos.org/content/html/D033/Policy.htm
[5] http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf
[6] 
https://www.usenix.org/conference/webapps12/gibraltar-exposing-hardware-devices-web-pages-using-ajax
[7] http://developer.chrome.com/trunk/apps/app_csp.html
[8] http://specs.wacapps.net/core/#processing-widget-signature
[9] 
https://docs.google.com/document/d/175vNhHLPdjYb7iwRBlLmSa3SsSIATpYZ7kpFyy-eYI0/edit

--
JohnLyle
Research Assistant
Department of Computer Science, University of Oxford