Security access level

In this section you will have an overview of KaiOS security framework, which is designed to protect mobile devices from threats to the platform, apps, and data. KaiOS has implemented a comprehensive security model, integrated, and multi-layered security model that delivers best-of-breed protection against security risks to mobile phones.

Platform Security

The KaiOS platform uses a multi-layered security model that is designed to mitigate exploitation risks at every level. Front-line countermeasures are combined with a defense-in-depth strategy that provides comprehensive protection against threats.

The KaiOS connects web-based applications to the underlying hardware. It is an integrated technology stack consisting of the following levels:

• Gaia: The suite of web apps that make up the user experience (apps consist of HTML5, CSS, JavaScript, images, media, and so on).
• Gecko: The application runtime layer that provides the framework for app execution, and implements the Web APIs used to access features in the mobile device.
• Gonk: The underlying Linux kernel, system libraries, firmware, and device drivers that everything runs on top of.
• The mobile device: The mobile phone running KaiOS.

Gecko is the gatekeeper that enforces security policies designed to protect the mobile device from misuse. The Gecko layer acts as the intermediary between web apps (at the Gaia layer) and the phone. Gonk delivers features of the underlying mobile phone hardware directly to the Gecko layer. Web apps access mobile phone functionality only through the Web APIs, and only if Gecko allows the access request — there is no direct access, no “back door” into the phone. Gecko enforces permissions and prevents access to unauthorized requests.

App Security

KaiOS uses a defense-in-depth security strategy to protect the mobile phone from intrusive or malicious applications. This strategy employs a variety of mechanisms, including implicit permission levels based on an app trust model, sandboxed execution at run time, API-only access to the underlying mobile phone hardware, a robust permissions model, and secure installation and update processes. For technical details, refer to Application security.

In KaiOS, all applications are web apps — programs written using HTML5, JavaScript, CSS, media, and other open web technologies (pages running within the browser are not referred to as web apps in this context). Because there are no binary ("native") applications installed by the user, all system access is mediated strictly through the Web APIs. Even access to the file system happens only through Web APIs and a back-end SQLite database — there is no direct access from apps to files stored on the SD card.

KaiOS limits and enforces the scope of resources that can be accessed or used by an app, while also supporting a wide range of apps with varying permission levels. Mozilla has implemented tight control over what type of applications can access which APIs. For example, only certified apps (shipped with the phone) can have access to the Telephony API. The Dialer app has privileges to access the Telephony API in order to make phone calls, but not all certified apps can access this API.

This prevents a situation, for example, in which an arbitrary third-party app gets installed, dials a pay-per-use phone number (900 and 910), and racks up a large cell phone bill.

Other OEM apps might be selectively given access to the Telephony API, however. For example, an operator might provide a systems management application that allows a customer to manage their account, including the ability to phone the Operator’s billing or support office directly.

Trusted and Untrusted Apps

KaiOS categorizes apps according to the following types:

Type	Trust Level	Description
Signed App with core	Highly Trusted	System apps that have been approved by the Operator or OEM (due to risk of device corruption or risk to critical functionality). System apps and services only; not intended for third-party applications. This designation is reserved for just a small number of critical applications. Examples: SMS, Bluetooth, camera, system clock, telephony, and the default dialer (to ensure that emergency services are always accessible).
Signed App	Trusted	Third-party apps that have been reviewed, approved, and digitally signed by an authorized KaiStore.
PWA (everything else)	Untrusted	Regular web content. Includes both installed apps (stored on the mobile phone) and hosted apps (stored remotely, with only an app manifest stored on the mobile phone). The manifest for hosted apps can be obtained through a KaiStore.

An application’s trust level determines, in part, its ability to access mobile phone functionality.

• Signed App with core have permissions to most Web API operations.
• signed apps have permissions to a subset of the Web API operations accessible to Certified apps.
• Untrusted apps have permissions to a subset of the Web API operations accessible to Privileged apps — only those Web APIs that contain sufficient security mitigations to be exposed to untrusted web content.

Some operations, such as network access, are assumed to be an implicit permission for all apps. In general, the more sensitive the operation (for example, dialing a phone number or accessing the Contacts list), the higher the app trust level required to execute it.

Note: for more information on the APIs available and their permission levels, consult App permissions.

Principle of Least Permissions

For PWA, the KaiOS security framework follows the principle of least permissions: start with the absolute minimum permissions, then selectively grant additional privileges only when required and reasonable. By default, an app starts with very low permissions, which is comparable to untrusted web content. If the app makes Web API calls that require additional permissions, it must enumerate these additional permissions in its manifest (described later in this document). Gecko will consider granting Web API access to an application only if the applicable privileges are explicitly requested in its manifest. Gecko will grant the requested permission only if the type of the Web App (certified, trusted, or web) is sufficiently qualified for access.

Packaged and Hosted Apps

Apps for KaiOS can be either packaged (stored on the mobile phone) or hosted (stored on a remote web server, with just a manifest stored on the mobile phone). There are some differences in the way in which security is managed for each. Nonetheless, packaged and hosted apps are both subject to application sandboxing, which is described later in this document.

Signed Apps

A Signed app consists of a ZIP file containing application resources (HTML5, CSS, JavaScript, images, media), as well as a manifest that provides an explicit list of assets and their corresponding hashes. Certified and privileged apps must be packaged apps because the app manifest needs to be digitally signed. When a user obtains a packaged app, the ZIP file is downloaded onto the mobile phone, and the manifest is read from a known location inside the ZIP file. During the install process, app assets are verified and remain stored locally in the package. All explicit permissions are requested at runtime, showing the user the app's data usage intentions, and persisted by default.

To refer to app resources in a packaged app, the URL begins with app: using the following format:

app://identifier/path_within_zipfile/file.html

where app:// represents the mount point for the ZIP file, and identifier is a UUID that is generated when the app is installed on the mobile phone. This mechanism ensures that resources referred to with an app: URL are contained in the ZIP file. The path within an app: is relative, so relative links to resources in the ZIP file are allowed.

While packaged apps are primarily intended to be used for Certified or Privileged apps, regular web apps can also be packaged. However, they do not gain any increase in trust or permissions access simply because they are packaged.

PWA Apps

PWA apps are located on a web server and loaded via HTTP. Only the app manifest is stored on the mobile phone. Everything else is stored remotely. Certain APIs are available only to privileged and certified apps, which requires the app to be packaged due to signing requirements. Therefore, a hosted app will not have access to any of the Web API operations that require privileged or certified app status.

From a security point of view, hosted apps work very much like normal websites. A hosted app is loaded by invoking a hard-coded, fully-qualified URL that points to the startup page in the root directory of the app on that web server. Once a hosted app is loaded, the mobile phone links to pages using the same URLs that are used when browsing the web site.

Security Settings in the App Manifest

The manifest can also contain other settings, including the following security settings:

Field	Description
permissions	Permissions required by the app. An app must list every Web API it intends to use that requires user permission. Most permissions make sense for privileged apps or certified apps, but not for hosted apps. Properties per API: description: A string specifying the intent behind requesting use of this API. Required. access: A string specifying the type of access required for the permission. Implicit permissions are granted at install time. Required for only a few APIs. Accepted values: read, readwrite, readcreate, and createonly.
csp	Content Security Policy (CSP). Applied to all pages loaded in the app. Used to harden the app against bugs that would allow an attacker to inject code into the app. If unspecified, privileged and certified apps have system-defined defaults.For security(XSS attack). All signed app(Packaged APP) Inline JavaScript is not allowed.
type	Type of application (PWA, or signed).

KaiOS requires that the manifest be served with a specific mime-type application/x-web-app-manifest+json and from the same fully-qualified host name (origin) from which the app is served. This restriction is relaxed when the manifest app (and thus the app manifest) is same-origin with the page that requested the app to be installed. This mechanism is used to ensure that it's not possible to trick a website into hosting an application manifest.

Security Infrastructure

The following figure shows the components of the KaiOS security framework:

• Permission Manager: Gateway to accessing functionality in the Web API, which is the only access to the underlying hardware.
• Access Control List: Matrix of roles and permissions required to access Web API functionality.
• Credential Validation: Authentication of apps/users.
• Permissions Store: Set of privileges required to access Web API functionality.