version: 1
-Date: 14 March 2016
+Date: 30 mai 2016
Author: José Bollo
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.
- - -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:
- -This document describes application framework fundamentals. +FCF (Fully Conform to Specification) implementation is still under development. +It may happen that current implementation somehow diverges with specifications.
-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:
+The application framework on top of the security framework +provides components to install and uninstall applications +as well as to run them in a secured environment.
-The goal of the framework is to manage applications and hide security details +to applications.
+For the reasons explained in introduction, it was choose not to reuse Tizen +application framework directly, but to rework a new framework inspired from Tizen.
-The figure below shows the history of these layers.
+fundamentals remain identical: the applications are distributed +in a digitally signed container that should match widget specifications +normalized by the W3C. This is described by the technical +recommendations widgets and widgets-digsig of the W3 consortium.
- 2014 2015
-Tizen OBS ----------+--------------------------->
- \
- \
- Tizen Yocto +---------+-------------->
- \
- \
- meta-intel-iot-security +----------->
-As today this model allows the distribution of HTML, QML and binary applications +but it could be extended to any other class of applications.
-We took the decision to use these security layers that provides the -basis of the Tizen security, the security framework.
+The management of widget package signatures. +Current model is only an initial step, it might be extended in the +future to include new feature (ie: incremental delivery).
-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.
+ +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 |
-+-----------------------------------------------------------------------+
-The main path for applications are: APPDIR/PKGID/VER.
-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:
+Where:
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.
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 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.
+The advantage of such an organization is to allow several versions to live together. +This is required for multiple reasons (ie: roll back) and to comply with developers habits.
-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.
+All the files are installed as user “userapp” and group “userapp”. +All files have rw(x) for user and r-(x) for group and others.
-The security framework of Tizen provides “nice lad” a valuable component to -scan log files and analyse auditing. This component is still in developement.
+This allows any user to read files.
- -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.
+The data of a user are contain within its directory and are labeled using the application labels
-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.
+For Tizen, the following rules are set by the security manager for each application.
- -System ~APP~ rwx
+System ~PKG~ rwxat
+System ~PKG~::RO rwxat
+~APP~ System wx
+~APP~ System::Shared rxl
+~APP~ System::Run rwxat
+~APP~ System::Log rwxa
+~APP~ _ l
+User ~APP~ rwx
+User ~PKG~ rwxat
+User ~PKG~::RO rwxat
+~APP~ User wx
+~APP~ User::Home rxl
+~APP~ User::App::Shared rwxat
+~APP~ ~PKG~ rwxat
+~APP~ ~PKG~::RO rxl
+Here, ~PKG~ is the identifier of the package and ~APP~ is the identifier of the application.
- -Not all user are able to run all applications. +How to manage that?