System Applications WG: Security Model
This is the Wiki page for the Security Model draft in the W3C System Applications WG
Related Work
- Firefox OS / Boot2Gecko / OpenWebDevice
- Application security model and discussion
- WebAPIs plus security related discussions
- Runtime security
- Manifest
- WAC and OMTP BONDI Security architectures
- WebOS (HP are making it hard to find references - root documentation page)
- Tizen security architecture
- Google Chrome (browser, applications, extensions)
- Process isolation
- Hosted applications - details on manifest permissions
- Chrome packaged applications - manifest permissions, disabled features, Identifying the user, Using CSP, Permissions warnings
- Webinos
- W3C DAP
- W3C Widget specifications
- ENISA - A Security Analysis of Next Generation Web Standards
- PhoneGap - Security wiki
- Opera Widgets and Opera Unite
- WebIntents and the extension to device services
- The state of the art in mobile web app standards
- Gibraltar: Exposing Hardware Devices to Web Pages Using AJAX by Kaisen Lin, UC San Diego; David Chu, James Mickens, Li Zhuang, and Feng Zhao, Microsoft Research; Jian Qiu, National University of Singapore. In the proceedings of the Third USENIX Conference on Web Application Development (WebApps’12). June, 2012.
More academic literature can be found here
Use Cases (list of links)
Use cases for system applications:
- A contacts application / address book ( http://sysapps.github.com/sysapps/proposals/Contacts/Contacts.html )
- An SMS application presenting SMS in interesting ways ( http://lists.w3.org/Archives/Public/public-sysapps/2012Oct/0043.html )
- A newspaper app (WG mailing list example from Wayne Carr)
- A text editor ( http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html )
- Accessing sensors
- http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0056.html
- webinos - accessing a heart rate monitor - http://www.webinos.org/blog/2012/08/17/heart-rate-monitor-sharing-data-services-with-your-friends/
- Media applications
- A photo viewer app with access to the user's "my photos" directory ( http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html )
- Loading media files, search, edit and store metadata. ( http://lists.w3.org/Archives/Public/public-sysapps/2012May/0038.html )
- Accessing media streams and sending them to other devices: http://www.webinos.org/blog/2012/07/02/webinos-demo-series-8-zap-and-shake-web-based-multi-screen-application/ and http://www.webinos.org/blog/2012/02/26/webinos-demo-series-1-slide-and-share-seamless-cross-device-media-management/
- Accessing DLNA / UPnP devices (webinos - https://github.com/webinos/webinos-design-data/blob/master/scenarios/S-CAP1.txt )
- A settings / permissions manager: a system application able to delegate management control of a device to another device.
- A built-in dialer application ( http://lists.w3.org/Archives/Public/public-sysapps/2013Jan/0006.html )
- A built-in contacts application ( http://lists.w3.org/Archives/Public/public-sysapps/2013Jan/0006.html )
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)
Requirements
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 - https://wiki.mozilla.org/B2G_App_Security_Model | 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 - https://wiki.mozilla.org/B2G_App_Security_Model | 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 - https://wiki.mozilla.org/B2G_App_Security_Model | 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 - https://wiki.mozilla.org/B2G_App_Security_Model | |
Immunity to browser-based threats | Apps should not be vulnerable to common web vulnerabilities when granted significant privileges | B2G - https://wiki.mozilla.org/B2G_App_Security_Model | 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 - https://wiki.mozilla.org/B2G_App_Security_Model | 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: http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html | 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 https://docs.google.com/spreadsheet/ccc?key=0As1cqcmobbEvdEhyOFN3ZU82QlMyR1FDUjlMSWRuM3c#gid=2 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)
- webinos: http://sysapps.github.com/sysapps/proposals/SecurityModel/RequirementsForSecurityModel.html
- Mozilla: http://mounirlamouri.github.com/sysapps/proposals/RunTime-Security/Overview.html