System Applications WG: Security Model

From W3C Wiki
Jump to: navigation, search

This is the Wiki page for the Security Model draft in the W3C System Applications WG

Related Work

More academic literature can be found here

Use Cases (list of links)

Use cases for system applications:

This list is clearly inadequate.

Basic question: if system applications were able to do anything that an Android or iOS application was able to do, would that be adequate? Or are system applications more or less powerful than that?

We could try and place System Applications somewhere in the following scale:

  • Web pages (not allowed to do very much)
  • W3C Widgets (allowed to do more than web pages, such as accessing more remote origins, but only in well-defined ways and not very extensive functionality)
  • Android applications (allowed to do most things, but only within their own sandbox and limited external storage)
  • PC executables / Debian packages (allowed to do anything in userspace for that user account)
  • Operating system services (able to do absolutely anything, including messing up the operating system)


Requirement Description Source Implications
Alarm API Applications can create alarms, notifying users SysApps Charter
Contacts API Apps can add, remove and edit contacts SysApps Charter
Messaging API Apps can send, receive and view SMS SysApps Charter
Telephony API Apps can access the telephony capabilities of the underlyling platform: dial a number, pick up a call, route to voicemail, access the call log SysApps Charter
Raw Sockets API Apps can create, manipulate and listen for low-level TCP and UDP connections SysApps Charter
Supports many device form factors Supports a wide variety of devices including desktop & laptop computers, smart phones, tablets, TVs, cameras, and other connected devices SysApps Charter The security model can make no assumptions about how the device will be used or shared between people and cannot assume a particular process model.
DAP API Support All APIs defined by DAP should be accessible to system applications SysApps Charter Either DAP APIs will need to change slightly in the systems context or the security model must allow for API-specific access controls
Minimal user prompting Problems such as 'double prompting' should be avoided when integrating other APIs SysApps Charter Some details of the expected user interactions may need to be specified in the security model or APIs
HTML5 Applications consist of HTML, CSS and JavaScript
Location Applications have access to geolocation data
Communicate with other applications Applications can communicate with other applications Some kind of messaging will be supported
Communicate with pre-defined endpoints Applications can communicate with pre-defined web addresses Access remote domains will be possible
Valid across multiple platforms Applications can run on any conformant platform, potentially including any device form factor Compatibility of application packages
Access control log Allow access control decisions to be logged. webinos
API access rationale Applications shall be able to explain why access to data or APIs is being requested. webinos
Application capability restriction Applications shall access only its specified device features, extensions and content. webinos
Application intent Applications shall specify its required functionality at install time or during updates. webinos
Application isolation Applications shall be isolated from each other. webinos
Application policy approval Changes to existing application intentions and permissions shall be approved by the end user. webinos
Authenticity check Before being installed or updated, origin authenticity and integrity checks shall be performed by the runtime webinos
Certifier list The list of authorities that certified an application shall be viewable by end-users. webinos
Confidential credentials storage The webinos runtime shall support the confidential storage of user credentials. webinos
Credentials access restriction Access to credentials storage shall be limited to a specific user, a specific device and a set of applications. webinos
Data management rationale applications shall be able to explain how collected sensitive data will be managed. webinos
Default policy A default security and privacy policy shall exist an be enforced on each conformant runtime webinos
Device-identity binding Personal devices shall be bound to their owner's identities. webinos
Device-identity binding revokation The binding between personal devices and owner's identity shall be revokable. webinos
Hierarchical policy enforcement Runtimes can enforce multiple access control rules written by multiple stakeholders in a hierarchy. webinos
Secure cache Data cached by a runtime shall be securely stored to prevent disclosure and tampering by unauthorised entitites. webinos
Secure storage Application data shall be securely stored to prevent disclosure and tampering by unauthorised entities. webinos
Trusted application source When installing or using an application for the first time, the runtime shall establish that the user trusts the source of the application. webinos Apps must have provenance data attached to them
App stores can revoke applications "An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app" B2G - App permissions can be changed remotely
External trusted party can set app default permissions B2G: "App store must be able to set the default permissions for an app". Extrapolated from B2G - The user is not the only source of access control decisions. this also suggests a need for conflict resolution.
Installation Applications must be installed before executed B2G, webinos
Owner override The device owner must be able to override app settings and permissions (this may not be the user, but a corporate, for example) B2G (user), webinos (user) Access control settings must be changeable
App privilege visibility Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment B2G - There must be a standard way for applications to identify the permissions they have and lack
Permission usability Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment B2G -
Immunity to browser-based threats Apps should not be vulnerable to common web vulnerabilities when granted significant privileges B2G - Non-browser security context: may be additional restrictions on HTML/JavaScript
Pre-installed app permissions Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties B2G - Different 'levels' apply to SysApps - possibly 'roles'
Access to files outside owned by the platform Ability for a system application to access (read and write) files outside of that application's sandboxed storage area. Mailing list: Need to provide both sandboxed and non-sandboxed storage

High-level Object Model

The following image is a high-level view of what the System Applications environment is. Concept Map Image (PlantUML)

Threat Model

This section should outline the list of potential threats that the security model will be dealing with.

See for source data (to be moved)

Threat Description
Misuse of user or application data through lack of transport security An application communicates insecurely with a remote server and a malicious party intercepts application or user data
Injection of code into trusted application through unauthenticated/compromised remote endpoint An application downloads executable code from a remote server which is modified by a malicious party either by compromising the server or the communication
Exploit weak credentials / bad session handling to create a session with an application host impersonating a legitimate user A malicious party exploits the session handling code used by the application to communicate with a remote server to impersonate the user
Client-side code injection through improperly controlled inputs An attacker uses an unauthenticated client-side API or injection method to inject malicious code and exploit the application's credentials
Malware installed by a malicious user with physical access An attacker with physical access to the device is able to install a malicious system-level application and misuse device capabilities and credentials
User installed malware A user accidentally installs malware not realising the implications of doing so. This malware is able to misuse device capabilities in various ways (see below)
User-installed grayware accessing more capabilities than the user wanted A user installs a genuine application but it operates in unexpected ways, violating user security requirements (excessive adverts, privacy invasion, data sharing).
Malware installed through app store compromise A trusted, legitimate source of applications (such as an app store) is remotely compromised in order to authorise and install malware on end user devices
Malware installed through side-loading Malware is installed through a channel which is not mediated by any malware checking process
Malware: destructive Malware misuses its permissions to delete data or cause harm to the device through APIs.
Malware: SMS / Telephony Malware misuses SMS or Telephony access to call or send text messages to expensive numbers
Malware: Contacts, spam and email misuse Malware misuses access to contact data in order to spam other users
Malware: adware Malware spoils the user experience by displaying excessive adverts
Malware: botnet, network misuse Malware behaves like a botnet, misusing the device's network connection to contact unknown services, lowering battery life and performance and potentially costing the user money
Malware: changing settings for novelty/amusement Malware is installed and annoys the user to the amusement of an attacker. No real harm is done.
Malware: credential and identity theft Malware gains access to credentials, email accounts or SMS inboxes allowing it (or the authors) to impersonate the user and defraud them. This may include defeating two-factor authentication.
Malware: blackmail Malware threatens to destroy user data or locks the user out of their device until payment is made to the attacker.
Malware: in-app billing Malware exploits the in-app billing capabilities of the device to charge the user money without authorisation.
Malware: UI spoofing for privilege escalation Malware phishes the end user by impersonating another application, stealing user credentials and adding new privileges
NFC abuse - exploiting a device's NFC interface (through proximity) to impersonate a user The device's NFC capabilities are used by malware to perform a relay attack (or otherwise) and impersonate the user somewhere else.
Device denial of service through API abuse Malware misuses APIs to the extent that the user is no longer able to use the device or some services. For instance, processor-intensive queries.
Circumvention of access control through access to other interfaces/APIs Malware is able to circumvent the platform's access control system through use of other APIs, interfaces or methods exposed by other applications in order to gain access to more features

WG Drafts

Proposals (list of links)

Cross Origin XHR

Cross Origin XHR