5 https://git.automotivelinux.org/src/app-framework-main/plain/docs/0-introduction.md?h=master
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 -->
10 # AGL framework overview
14 This document describes what we intend to do.
15 It may happen that our current implementation and the content of this document differ.
17 In case of differences, it is assumed that this document is right
18 and the implementation is wrong.
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.
27 Here is a minimal list of what was needed:
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
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:
44 - libtzplatform-config
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.
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 :
58 - **security-manager**
59 - **D-Bus aware of cynara**
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:
67 - Implementing Smack LSM
68 - Implementing Integrity Measurement Architecture
69 - Implementing Tizen Security Framework
71 The figure below shows the history of these layers.
73 ![Security_model_history][Security_model_history]
75 We took the decision to use these security layers that provide the
76 basis of the Tizen security, the security framework.
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.
84 These components are :
86 - **afm-system-daemon**
89 They provides infrastructure for installing, uninstalling,
90 launching, terminating, pausing and resuming applications in
91 a multi user secure environment.
93 A third component exists in the framework, the binder **afb-daemon**.
94 The binder provides the easiest way to provide secured API for
96 Currently, the use of the binder is not absolutely mandatory.
98 This documentation explains the framework created by IoT.bzh
99 by rewriting the Tizen Application Framework.
100 Be aware of the previous foreword.
106 The figure below shows the major components of the framework
107 and their interactions going through the following scenario:
109 - APPLICATION installs an other application and then launch it.
111 ![AppFW-APP_install_sequences][AppFW-APP_install_sequences]{:: style="width:70%;"}
113 Let follow the sequence of calls:
115 1. APPLICATION calls its **binder** to install the OTHER application.
117 1. The binding **afm-main-binding** of the **binder** calls, through
118 **D-Bus** system, the system daemon to install the OTHER application.
120 1. The system **D-Bus** checks wether APPLICATION has the permission
121 or not to install applications by calling **CYNARA**.
123 1. The system **D-Bus** transmits the request to **afm-system-daemon**.
125 **afm-system-daemon** checks the application to install, its
126 signatures and rights and install it.
128 1. **afm-system-daemon** calls **SECURITY-MANAGER** for fulfilling
129 security context of the installed application.
131 1. **SECURITY-MANAGER** calls **CYNARA** to install initial permissions
134 1. APPLICATION call its binder to start the nearly installed OTHER application.
136 1. The binding **afm-main-binding** of the **binder** calls, through
137 **D-Bus** session, the user daemon to launch the OTHER application.
139 1. The session **D-Bus** checks wether APPLICATION has the permission
140 or not to start an application by calling **CYNARA**.
142 1. The session **D-Bus** transmits the request to **afm-user-daemon**.
144 1. **afm-user-daemon** checks wether APPLICATION has the permission
145 or not to start the OTHER application **CYNARA**.
147 1. **afm-user-daemon** uses **SECURITY-MANAGER** features to set
148 the security context for the OTHER application.
150 1. **afm-user-daemon** launches the OTHER application.
152 This scenario does not cover all the features of the frameworks.
153 Shortly because details will be revealed in the next chapters,
156 - ***SECURITY-MANAGER***: in charge of setting Smack contexts and rules,
157 of setting groups, and, of creating initial content of *CYNARA* rules
160 - ***CYNARA***: in charge of handling API access permissions by users and by
163 - ***D-Bus***: in charge of checking security of messaging. The usual D-Bus
164 security rules are enhanced by *CYNARA* checking rules.
166 - ***afm-system-daemon***: in charge of installing and uninstalling applications.
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.
172 - ***afb-binder***: in charge of serving resources and features through an
175 - ***afm-main-binding***: This binding allows applications to use the API
176 of the AGL framework.
178 ## Links between the "Security framework" and the "Application framework"
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.
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
189 The application framework manages the applications:
198 The application framework uses the security model/framework
199 to ensure the security and the privacy of the applications that
202 The application framework must be compliant with the underlying
203 security model/framework.
204 But it should hide it to the applications.
206 ## The security framework
208 The implemented security model is the security model of Tizen 3.
209 This model is described [here][tizen-secu-3].
211 The security framework then comes from Tizen 3 but through
215 - **Security-Manager**
217 - **D-Bus** compliant to Cynara.
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.
223 **In theory, the security framework/model is an implementation details
224 that should not impact the layers above the application framework**.
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.
230 ## The application framework
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.
236 The goal is to manage applications and to hide the details of
237 the security framework to the applications.
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.
242 The basis is kept identical:
244 - The applications are distributed in a digitally signed container that must
245 match the specifications of widgets (web applications).
247 This is described by the technical recommendations [widgets] and
248 [widgets-digsig] of the W3 consortium.
252 - The distribution of HTML, QML and binary applications.
253 - The management of signatures of the widget packages.
255 This basis is not meant as being rigid and it can be extended in the
256 future to include for example incremental delivery.
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