doc/overview.html

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