doc/overview.md

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