doc/application-framework.md

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