docs/overview.md

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