Crosswalk:API Permission Control

From Tizen Wiki
Jump to: navigation, search

This document describes the design to implement API permission control for Tizen platform.

Introduction

Crosswalk should provide API level access control for security sensitive operations which, if not used correctly, can harm user privacy and system stability. A subset of the JavaScript APIs supported in Crosswalk are considered restricted. Restricted refers to any JS function that can access the private data on a device such as location, contacts, calendar, etc. If these restricted APIs are not used correctly, running unsafe application can harm user privacy and system stability.

Background

  • Crosswalk: it runs as web runtime in Tizen platform. Each running web application is composed of three process, which are as below. Browser process is shared by web applications in the same user. Each web application has unique render and extension process.
  • Browser Process (BP)
  • Render Process(RP)
  • Extension Process(EP)

Crosswalk Process Model

  • Cynara: It is a services that are being used by applications need to control if the caller has sufficient privileges to call each API. Cynara provides two libraries for  application's policy management and privilege check.


Note:Although most of Tizen privileges should be provided by services, some of them will be handled by direct access to a file-system object. These exceptions cannot be handled by Cynara. We designed a group-based model for this case. Appropriate file-system objects will be owned by a designated system group. During launch, together with setting SMACK labels, process groups should be set to get access to these resources

  • Security-manager: It provides APIs to set up SMACK label for extension and render process. Also it provides API to set up Cynara permission database.
  • SMACK(Simplified Mandatory Access Control Kernel): It is is the main system-level access control mechanism. Each file and running process in Tizen should have a SMACK label. For Crosswalk, each web app has a unique SMACK label(used by render and extension process). Browser process has a separate SMACK label than web apps.

Sub Tasks for the Feature

In general, there are three steps to handle API permissions in Crosswalk.

  1. Setting SMACK labels for resource files and SMACK rules during installing web app
  2. Set SMACK label for extension and render process during launching web app
  3. Checking privilege in executing a sensitive web JS API


The procedure for each is described more fully in the sections below.

Overview of Setting SMACK Label during Installation

The installation policy is applied during installing a new Crosswalk application. The installer is responsible for the permission filter and set appropriate SMACK label/rules.
The installer will read the required permissions from a package’s config.xml, then extract and copy files, set up appropriate permissions and write into Cynara databases.
The following diagram attempts to give an overview of installing web applications on Tizen.

API Permission Install.png
The general flow of installing application is as below:

  1. Crosswalk installer unzip Crosswalk web application package
  2. Crosswalk installer verify signature of the package. If the package is a valid package, Crosswalk judge the privilege level according to distributor signature.
  3. Crosswalk extract permissions list from config.xml.
  4. According to privilege level, Crosswalk filter invalid permissions out of permissions list.
  5. Crosswalk installer calls security-manager to insert policies for resource files and permissions.
  1. Security manager calculates SMACK label for the web app according to application id
  2. Security manager sets up SMACK labels for resource files of the web app
  3. Security manager sets up SMACK rules in the SMACK DB for Crosswalk browser process label and web app label.
  4. Security manager calls Cynara-admin to set up permission policies.

Overview of Setting up SMACK Label for EP and RP

The following diagram attempts to give an overview of launching web applications on Tizen.
API Permission Set SMACK.png
The graph outlined above illustrated the process by which a Crosswalk application is created.
The general process is as below:

  1. User trying to launch an application by clicking the application icon in home screen or another application throwing an intent to launch web app, which result in a series of IPC message passing between multiple processes and eventually the launchpad_daemon is notified of this action.  
  2. The launchpad_daemon fork a child process xwalk-launcher and xwalk-launcher create a new xwalk extension process instance. xwalk-launcher set SMACK label for itself.
  3. xwalk-launcher send an dbus message to running application manager (Browser process). Application manager launch web application and start a new render view(render process).
  4. Render process set itself SMACK label Render process adds itself to required supplementary groups. To be allowed to do that, it also needs CAP_SETGID capability

Note:

  • The launchpad_daemon is not a part of Crosswalk but a Tizen system component. It works together smoothly with the other Tizen components like amd (application management daemon).
  • The launchpad_daemon runs as root, which currently is the default behaviour of Tizen.
  • Render process must switch its SMACK label to web app SMACK label as early as possible.
  • The process must drop the capability “CAP_MAC_ADMIN” right after its SMACK label is switched.
  • In XWalkContentRendererClient::RenderThreadStarted(), we should set SMACK label for render process here

Overview of Checking Permission in Runtime

Crosswalk should API permission check in the browser process for some W3C API such as geolocation, media and so on.
Note:

  • API permissions check for Tizen device API, which is running in extension process,  is done by Tizen system.

The following diagram attempts to give an overview of checking API permission in the browser process.
API Permission Runtime Checking.png
The general process is as below:

  • When a sensitive W3C JS API is invoked, RP send IPC to BP
  • BP use specific embedder to request permission;
  1. Embedder creates a separated security thread in RequestxxxPermission.
  2. Embedder post a task to security thread with appid,  privilege information.
  • Security thread call libCynara to check privilege
  • Cynara return ALLOW/DENY to Security thread
  • After security thread get result from Cynara, security thread call callback from embedder
  • If the operation is allowed, BP call core library