docs/3_Developer_Guides/1_Application_Framework/0_Introduction.md

   1 ---
   2 title: Introduction
   3 ---
   4
   5 ## Foreword
   6
   7 This document describes what we intend to do.
   8 It may happen that our current implementation and the content of this document differ.
   9
  10 In case of differences, it is assumed that this document is right and the implementation is wrong.
  11
  12 ## Introduction
  13
  14 During the first works in having the security model of Tizen integrated in AGL
  15 (Automotive Grade Linux) distribution, it became quickly obvious that the count
  16 of components specific to Tizen to integrate was huge.
  17
  18 Here is a minimal list of what was needed:
  19
  20 - platform/appfw/app-installers
  21 - platform/core/security/cert-svc
  22 - platform/core/appfw/ail
  23 - platform/core/appfw/aul-1
  24 - platform/core/appfw/libslp-db-util
  25 - platform/core/appfw/pkgmgr-info
  26 - platform/core/appfw/slp-pkgmgr
  27
  28 But this list isn't complete because many dependencies are hidden.
  29 Those hidden dependencies are including some common libraries but also many
  30 tizen specific sub-components:
  31
  32 - iniparser
  33 - bundle
  34 - dlog,
  35 - libtzplatform-config
  36 - db-util
  37 - vconf-buxton
  38 - ...
  39
  40 This is an issue because AGL is not expected to be Tizen.
  41 Taking it would either need to patch it for removing unwanted components or to take all of them.
  42
  43 However, a careful study of the core components of the security framework
  44 of Tizen showed that their dependencies to Tizen are light (and since some
  45 of our work, there is no more dependency to tizen).
  46 Those components are :
  47
  48 - **cynara**
  49 - **security-manager**
  50 - **D-Bus aware of cynara**
  51
  52 Luckily, these core security components of Tizen are provided
  53 by [meta-intel-iot-security][meta-intel], a set of yocto layers.
  54 These layers were created by Intel to isolate Tizen specific security
  55 components from the initial port of Tizen to Yocto.
  56 The 3 layers are providing components for:
  57
  58 - Implementing Smack LSM
  59 - Implementing Integrity Measurement Architecture
  60 - Implementing Tizen Security Framework
  61
  62 The figure below shows the history of these layers.
  63
  64 ![Security_model_history](./pictures/Security_model_history.svg)
  65
  66 We took the decision to use these security layers that provide the
  67 basis of the Tizen security, the security framework.
  68
  69 For the components of the application framework, built top of
  70 the security framework, instead of pulling the huge set of packages
  71 from Tizen, we decided to refit it by developing a tiny set of
  72 components that would implement the same behaviour but without all
  73 the dependencies and with minor architectural improvements for AGL.
  74
  75 These components are :
  76
  77 - **afm-system-daemon**
  78 - **afm-user-daemon**
  79
  80 They provides infrastructure for installing, uninstalling,
  81 launching, terminating, pausing and resuming applications in
  82 a multi user secure environment.
  83
  84 A third component exists in the framework, the binder **afb-daemon**.
  85 The binder provides the easiest way to provide secured API for
  86 any tier.
  87 Currently, the use of the binder is not absolutely mandatory.
  88
  89 This documentation explains the framework created by IoT.bzh
  90 by rewriting the Tizen Application Framework.
  91 Be aware of the previous foreword.
  92
  93 ## Overview
  94
  95 The figure below shows the major components of the framework
  96 and their interactions going through the following scenario:
  97
  98 - APPLICATION installs an other application and then launch it.
  99    ![AppFW-APP_install_sequences](./pictures/AppFW-APP_install_sequences.svg)
 100
 101 Let follow the sequence of calls:
 102
 103 1. APPLICATION calls its **binder** to install the OTHER application.
 104
 105 1. The binding **afm-main-binding** of the **binder** calls, through
 106    **D-Bus** system, the system daemon to install the OTHER application.
 107
 108 1. The system **D-Bus** checks wether APPLICATION has the permission
 109    or not to install applications by calling **CYNARA**.
 110
 111 1. The system **D-Bus** transmits the request to **afm-system-daemon**.
 112
 113    **afm-system-daemon** checks the application to install, its
 114    signatures and rights and install it.
 115
 116 1. **afm-system-daemon** calls **SECURITY-MANAGER** for fulfilling
 117    security context of the installed application.
 118
 119 1. **SECURITY-MANAGER** calls **CYNARA** to install initial permissions
 120    for the application.
 121
 122 1. APPLICATION call its binder to start the nearly installed OTHER application.
 123
 124 1. The binding **afm-main-binding** of the **binder** calls, through
 125    **D-Bus** session, the user daemon to launch the OTHER application.
 126
 127 1. The session **D-Bus** checks wether APPLICATION has the permission
 128    or not to start an application by calling **CYNARA**.
 129
 130 1. The session **D-Bus** transmits the request to **afm-user-daemon**.
 131
 132 1. **afm-user-daemon** checks wether APPLICATION has the permission
 133     or not to start the OTHER application **CYNARA**.
 134
 135 1. **afm-user-daemon** uses **SECURITY-MANAGER** features to set
 136     the security context for the OTHER application.
 137
 138 1. **afm-user-daemon** launches the OTHER application.
 139
 140 This scenario does not cover all the features of the frameworks.
 141 Shortly because details will be revealed in the next chapters,
 142 the components are:
 143
 144 - ***SECURITY-MANAGER***: in charge of setting Smack contexts and rules,
 145   of setting groups, and, of creating initial content of *CYNARA* rules
 146   for applications.
 147
 148 - ***CYNARA***: in charge of handling API access permissions by users and by
 149   applications.
 150
 151 - ***D-Bus***: in charge of checking security of messaging. The usual D-Bus
 152   security rules are enhanced by *CYNARA* checking rules.
 153
 154 - ***afm-system-daemon***: in charge of installing and uninstalling applications.
 155
 156 - ***afm-user-daemon***: in charge of listing applications, querying application details,
 157   starting, terminating, pausing, resuming applications and their instances
 158   for a given user context.
 159
 160 - ***afb-binder***: in charge of serving resources and features through an
 161   HTTP interface.
 162
 163 - ***afm-main-binding***: This binding allows applications to use the API
 164   of the AGL framework.
 165
 166 ## Links between the "Security framework" and the "Application framework"
 167
 168 The security framework refers to the security model used to ensure
 169 security and to the tools that are provided for implementing that model.
 170
 171 The security model refers to how DAC (Discretionary Access Control),
 172 MAC (Mandatory Access Control) and Capabilities are used by the system
 173 to ensure security and privacy.
 174 It also includes features of reporting using audit features and by managing
 175 logs and alerts.
 176
 177 The application framework manages the applications:
 178
 179 - installing
 180 - uninstalling
 181 - starting
 182 - pausing
 183 - listing
 184 - ...
 185
 186 The application framework uses the security model/framework
 187 to ensure the security and the privacy of the applications that
 188 it manages.
 189
 190 The application framework must be compliant with the underlying
 191 security model/framework.
 192 But it should hide it to the applications.
 193
 194 ## The security framework
 195
 196 The implemented security model is the security model of Tizen 3.
 197 This model is described [here][tizen-secu-3].
 198
 199 The security framework then comes from Tizen 3 but through
 200 the [meta-intel].
 201 It includes:
 202
 203 - **Security-Manager**
 204 - **Cynara**
 205 - **D-Bus** compliant to Cynara.
 206
 207 Two patches are applied to the security-manager.
 208 The goal of these patches is to remove specific dependencies with Tizen packages that are not needed by AGL.
 209 None of these patches adds or removes any behaviour.
 210
 211 **In theory, the security framework/model is an implementation details
 212 that should not impact the layers above the application framework**.
 213
 214 The security framework of Tizen provides "nice lad" a valuable component to
 215 scan log files and analyse auditing.
 216 This component is still in development.
 217
 218 ## The application framework
 219
 220 The application framework on top of the security framework
 221 provides the components to install and uninstall applications
 222 and to run it in a secured environment.
 223
 224 The goal is to manage applications and to hide the details of
 225 the security framework to the applications.
 226
 227 For the reasons explained in introduction, we did not used the
 228 application framework of Tizen as is but used an adaptation of it.
 229
 230 The basis is kept identical:
 231
 232 - The applications are distributed in a digitally signed container that must
 233   match the specifications of widgets (web applications).
 234
 235 This is described by the technical recommendations [widgets] and
 236 [widgets-digsig] of the W3 consortium.
 237
 238 This model allows:
 239
 240 - The distribution of HTML, QML and binary applications.
 241 - The management of signatures of the widget packages.
 242
 243 This basis is not meant as being rigid and it can be extended in the
 244 future to include for example incremental delivery.
 245
 246 [meta-intel]:       https://github.com/01org/meta-intel-iot-security                "A collection of layers providing security technologies"
 247 [widgets]:          http://www.w3.org/TR/widgets                                    "Packaged Web Apps"
 248 [widgets-digsig]:   http://www.w3.org/TR/widgets-digsig                             "XML Digital Signatures for Widgets"
 249 [libxml2]:          http://xmlsoft.org/html/index.html                              "libxml2"
 250 [openssl]:          https://www.openssl.org                                         "OpenSSL"
 251 [xmlsec]:           https://www.aleksey.com/xmlsec                                  "XMLSec"
 252 [json-c]:           https://github.com/json-c/json-c                                "JSON-c"
 253 [d-bus]:            http://www.freedesktop.org/wiki/Software/dbus                   "D-Bus"
 254 [libzip]:           http://www.nih.at/libzip                                        "libzip"
 255 [cmake]:            https://cmake.org                                               "CMake"
 256 [security-manager]: https://wiki.tizen.org/wiki/Security/Tizen_3.X_Security_Manager "Security-Manager"
 257 [app-manifest]:     http://www.w3.org/TR/appmanifest                                "Web App Manifest"
 258 [tizen-security]:   https://wiki.tizen.org/wiki/Security                            "Tizen security home page"
 259 [tizen-secu-3]:     https://wiki.tizen.org/wiki/Security/Tizen_3.X_Overview         "Tizen 3 security overview"
 260 [AppFW-APP_install_sequences]: pictures/AppFW-APP_install_sequences.svg
 261 [Security_model_history]: pictures/Security_model_history.svg