From ddd10705d70b598160a41d197f364d2f792359f5 Mon Sep 17 00:00:00 2001 From: José Bollo Date: Tue, 15 Mar 2016 09:51:56 +0100 Subject: doc: create documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Create more documentation about afm-main. Change-Id: I8b73017b666ac42da248df4219ec7abc08c7e877 Signed-off-by: José Bollo --- doc/application-framework.html | 290 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 290 insertions(+) create mode 100644 doc/application-framework.html (limited to 'doc/application-framework.html') diff --git a/doc/application-framework.html b/doc/application-framework.html new file mode 100644 index 0000000..f77ee48 --- /dev/null +++ b/doc/application-framework.html @@ -0,0 +1,290 @@ + + + + + + + +

Application framework

+ +

version: 1
+Date:    14 March 2016
+Author:  José Bollo
+

+ + +

Foreword

+ +

This document describes what we intend to do. It may happen that our +current implementation and the content of this document differ.

+ +

In case of differences, it is assumed that this document is right +and the implementation is wrong.

+ + +

Introduction

+ +

During the first works in having the security model of Tizen +integrated in AGL (Automotive Grade Linux) distribution, it became +quickly obvious that the count of components specific to Tizen +to integrate was huge.

+ +

Here is a minimal list of what was needed:

+ +

platform/appfw/app-installers
platform/core/security/cert-svc
platform/core/appfw/ail
platform/core/appfw/aul-1
platform/core/appfw/libslp-db-util
platform/core/appfw/pkgmgr-info
platform/core/appfw/slp-pkgmgr

+ + +

But this list is complete because many dependencies are hidden. +Those hidden dependencies are including some common libraries but also many +tizen specific sub-components (iniparser, bundle, dlog, libtzplatform-config, +db-util, vconf-buxton, …).

+ +

This is an issue because AGL is not expected to be Tizen. Taking it would +either need to patch it for removing unwanted components or to take all +of them.

+ +

However, a careful study of the core components of the security framework +of Tizen showed that their dependencies to Tizen are light (and since some +of our work, there is no more dependency to tizen). +Those components are cynara, security-manager, D-Bus aware of cynara.

+ +

Luckyly, these core security components of Tizen are provided +by meta-intel-iot-security, a set of yocto layers. +These layers were created by Intel to isolate Tizen specific security +components from the initial port of Tizen to Yocto. +The 3 layers are providing components for:

+ +

Implementing Smack LSM
Implementing Integrity Measurement Architecture
Implementing Tizen Security Framework

+ + +

The figure below shows the history of these layers.

+ +

                  2014         2015
+Tizen OBS ----------+--------------------------->
+                     \
+                      \
+     Tizen Yocto       +---------+-------------->
+                                  \
+                                   \
+       meta-intel-iot-security      +----------->
+

+ +

We took the decision to use these security layers that provides the +basis of the Tizen security, the security framework.

+ +

For the components of the application framework, built top of +the security framework, instead of pulling the huge set of packages +from Tizen, we decided to refit it by developping a tiny set of +components that would implement the same behaviour but without all +the dependencies and with minor architectural improvements for AGL.

+ +

These components are afm-system-daemon and afm-user-daemon. +They provides infrastructure for installing, uninstalling, +launching, terminating, stopping and resuming applications in +a multi user secure environment.

+ +

A third component exists in the framework, the binder afb-daemon. +The binder provides the easiest way to provide secured API for +any tier. Currently, the use of the binder is not absolutely mandatory.

+ +

This documentation explains the framework created by IoT.bzh +by rewriting the Tizen Application Framework. Be aware of the +previous foreword.

+ + +

Overview

+ +

The figure below shows the major components of the framework +and their interactions going through the following scenario: +APPLICATION installs an other application and then launch it.

+ +

+-----------------------------------------------------------------------+
+|                                 User                                  |
+|  ................................                                     |
+|  :   Smack isolation context    :                                     |
+|  :                              :      ...........................    |
+|  :  +-----------------------+   :      : Smack isolation context :    |
+|  :  |                       |   :      :                         :    |
+|  :  |      APPLICATION      |   :      :     OTHER application   :    |
+|  :  |                       |   :      :.........................:    |
+|  :  +-----------+-----------+   :                ^                    |
+|  :              |               :                |                    |
+|  :              |(1),(7)        :                |(13)                |
+|  :              |               :                |                    |
+|  :  +-----------v-----------+   :      +---------+---------------+    |
+|  :  |   binder afb-daemon   |   :      |                         |    |
+|  :  +-----------------------+   :      |      afm-user-daemon    |    |
+|  :  |    afm-main-plugin    |   :      |                         |    |
+|  :  +-----+--------------+--+   :      +------^-------+------+---+    |
+|  :........|..............|......:             |       |      :        |
+|           |(2)           |(8)                 |(10)   |      :        |
+|           |              |                    |       |      :        |
+|           |         +----v--------------------+---+   |      :        |
+|           |         |        D-Bus   session      |   |(11)  :(12)    |
+|           |         +-------------------------+---+   |      :        |
+|           |                                   |       |      :        |
+|           |                                   |(9)    |      :        |
+|           |                                   |       |      :        |
+:===========|===================================|=======|======:========:
+|           |                                   |       |      :        |
+|           |                               +---v-------v--+   :        |
+|    +------v-------------+     (3)         |              |   :        |
+|    |  D-Bus   system    +----------------->    CYNARA    |   :        |
+|    +------+-------------+                 |              |   :        |
+|           |                               +------^-------+   :        |
+|           |(4)                                   |           :        |
+|           |                                      |(6)        v        |
+|    +------v--------------+             +---------+---------------+    |
+|    |                     |    (5)      |                         |    |
+|    |  afm-system-daemon  +------------->     SECURITY-MANAGER    |    |
+|    |                     |             |                         |    |
+|    +---------------------+             +-------------------------+    |
+|                                                                       |
+|                              System                                   |
++-----------------------------------------------------------------------+
+

+ +

Let follow the sequence of calls:

+ +

APPLICATION calls its binder to install the OTHER application.
The plugin afm-main-plugin of the binder calls, through +D-Bus system, the system daemon to install the OTHER application.
The system D-Bus checks wether APPLICATION has the permission +or not to install applications by calling CYNARA.
The system D-Bus transmits the request to afm-system-daemon.
+ +
afm-system-daemon checks the application to install, its +signatures and rights and install it.
afm-system-daemon calls SECURITY-MANAGER for fullfilling +security context of the installed application.
SECURITY-MANAGER calls CYNARA to install initial permissions +for the application.
APPLICATION call its binder to start the nearly installed OTHER application.
The plugin afm-main-plugin of the binder calls, through +D-Bus session, the user daemon to launch the OTHER application.
The session D-Bus checks wether APPLICATION has the permission +or not to start an application by calling CYNARA.
The session D-Bus transmits the request to afm-user-daemon.
afm-user-daemon checks wether APPLICATION has the permission +or not to start the OTHER application CYNARA.
afm-user-daemon uses SECURITY-MANAGER features to set +the seciruty context for the OTHER application.
afm-user-daemon launches the OTHER application.

+ + +

This scenario does not cover all the features of the frameworks. +Shortly because details will be revealed in the next chapters, +the components are:

+ +

SECURITY-MANAGER: in charge of setting Smack contexts and rules, +of setting groups, and, of creating initial content of CYNARA rules +for applications.
CYNARA: in charge of handling API access permissions by users and by +applications.
D-Bus: in charge of checking security of messaging. The usual D-Bus +security rules are enhanced by CYNARA checking rules.
afm-system-daemon: in charge of installing and uninstalling applications.
afm-user-daemon: in charge of listing applications, querying application details, +starting, terminating, stopping, resuming applications and their instances +for a given user context.
afb-binder: in charge of serving resources and features through an +HTTP interface.
afm-main-plugin: This plugin allows applications to use the API +of the AGL framework.

+ + + +

Links between the “Security framework” and the “Application framework”

+ +

The security framework refers to the security model used to ensure +security and to the tools that are provided for implementing that model.

+ +

The security model refers to how DAC (Discretionnary Access Control), +MAC (Mandatory Access Control) and Capabilities are used by the system +to ensure security and privacy. It also includes features of reporting +using audit features and by managing logs and alerts.

+ +

The application framework manages the applications: +installing, uninstalling, starting, stopping, listing …

+ +

The application framework uses the security model/framework +to ensure the security and the privacy of the applications that +it manages.

+ +

The application framework must be compliant with the underlyiong +security model/framework. But it should hide it to the applications.

+ + +

The security framework

+ +

The implemented security model is the security model of Tizen 3. +This model is described here.

+ +

The security framework then comes from Tizen 3 but through +the meta-intel. +It includes: Security-Manager, Cynara +and D-Bus compliant to Cynara.

+ +

Two patches are applied to the security-manager. These patches are removing +dependencies to packages specific of Tizen but that are not needed by AGL. +None of these patches adds or removes any behaviour.

+ +

Theoritically, the security framework/model is an implementation details +that should not impact the layers above the application framework.

+ +

The security framework of Tizen provides “nice lad” a valuable component to +scan log files and analyse auditing. This component is still in developement.

+ + +

The application framework

+ +

The application framework on top of the security framework +provides the components to install and uninstall applications +and to run it in a secured environment.

+ +

The goal is to manage applications and to hide the details of +the security framework to the applications.

+ +

For the reasons explained in introduction, we did not used the +application framework of Tizen as is but used an adaptation of it.

+ +

The basis is kept identical: the applications are distributed +in a digitally signed container that must match the specifications +of widgets (web applications). This is described by the technical +recomendations widgets and widgets-digsig of the W3 consortium.

+ +

This model allows the distribution of HTML, QML and binary applications.

+ +

The management of signatures of the widget packages +This basis is not meant as being rigid and it can be extended in the +futur to include for example incremental delivery.

+ + +

Comparison to other frameworks

+ + +

Tizen framework

+ + +

xdg-app

+ + +

ostro

+ + -- cgit 1.2.3-korg