docs/4_APIs_and_Services/4.2_Application_Framework/0_introduction.md

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