docs/0-introduction.md

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