7 This document describes what we intend to do.
8 It may happen that our current implementation and the content of this document differ.
10 In case of differences, it is assumed that this document is right and the implementation is wrong.
14 During the first works in having the security model of Tizen integrated in AGL
15 (Automotive Grade Linux) distribution, it became quickly obvious that the count
16 of components specific to Tizen to integrate was huge.
18 Here is a minimal list of what was needed:
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
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:
35 - libtzplatform-config
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.
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 :
49 - **security-manager**
50 - **D-Bus aware of cynara**
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:
58 - Implementing Smack LSM
59 - Implementing Integrity Measurement Architecture
60 - Implementing Tizen Security Framework
62 The figure below shows the history of these layers.
64 ![Security_model_history](./images/Security_model_history.svg)
66 We took the decision to use these security layers that provide the
67 basis of the Tizen security, the security framework.
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.
75 These components are :
77 - **afm-system-daemon**
80 They provides infrastructure for installing, uninstalling,
81 launching, terminating, pausing and resuming applications in
82 a multi user secure environment.
84 A third component exists in the framework, the binder **afb-daemon**.
85 The binder provides the easiest way to provide secured API for
87 Currently, the use of the binder is not absolutely mandatory.
89 This documentation explains the framework created by IoT.bzh
90 by rewriting the Tizen Application Framework.
91 Be aware of the previous foreword.
95 The figure below shows the major components of the framework
96 and their interactions going through the following scenario:
98 - APPLICATION installs an other application and then launch it.
99 ![AppFW-APP_install_sequences](./images/AppFW-APP_install_sequences.svg)
101 Let follow the sequence of calls:
103 1. APPLICATION calls its **binder** to install the OTHER application.
105 1. The binding **afm-main-binding** of the **binder** calls, through
106 **D-Bus** system, the system daemon to install the OTHER application.
108 1. The system **D-Bus** checks wether APPLICATION has the permission
109 or not to install applications by calling **CYNARA**.
111 1. The system **D-Bus** transmits the request to **afm-system-daemon**.
113 **afm-system-daemon** checks the application to install, its
114 signatures and rights and install it.
116 1. **afm-system-daemon** calls **SECURITY-MANAGER** for fulfilling
117 security context of the installed application.
119 1. **SECURITY-MANAGER** calls **CYNARA** to install initial permissions
122 1. APPLICATION call its binder to start the nearly installed OTHER application.
124 1. The binding **afm-main-binding** of the **binder** calls, through
125 **D-Bus** session, the user daemon to launch the OTHER application.
127 1. The session **D-Bus** checks wether APPLICATION has the permission
128 or not to start an application by calling **CYNARA**.
130 1. The session **D-Bus** transmits the request to **afm-user-daemon**.
132 1. **afm-user-daemon** checks wether APPLICATION has the permission
133 or not to start the OTHER application **CYNARA**.
135 1. **afm-user-daemon** uses **SECURITY-MANAGER** features to set
136 the security context for the OTHER application.
138 1. **afm-user-daemon** launches the OTHER application.
140 This scenario does not cover all the features of the frameworks.
141 Shortly because details will be revealed in the next chapters,
144 - ***SECURITY-MANAGER***: in charge of setting Smack contexts and rules,
145 of setting groups, and, of creating initial content of *CYNARA* rules
148 - ***CYNARA***: in charge of handling API access permissions by users and by
151 - ***D-Bus***: in charge of checking security of messaging. The usual D-Bus
152 security rules are enhanced by *CYNARA* checking rules.
154 - ***afm-system-daemon***: in charge of installing and uninstalling applications.
156 - ***afm-user-daemon***: in charge of listing applications, querying application details,
157 starting, terminating, pausing, resuming applications and their instances
158 for a given user context.
160 - ***afb-binder***: in charge of serving resources and features through an
163 - ***afm-main-binding***: This binding allows applications to use the API
164 of the AGL framework.
166 ## Links between the "Security framework" and the "Application framework"
168 The security framework refers to the security model used to ensure
169 security and to the tools that are provided for implementing that model.
171 The security model refers to how DAC (Discretionary Access Control),
172 MAC (Mandatory Access Control) and Capabilities are used by the system
173 to ensure security and privacy.
174 It also includes features of reporting using audit features and by managing
177 The application framework manages the applications:
186 The application framework uses the security model/framework
187 to ensure the security and the privacy of the applications that
190 The application framework must be compliant with the underlying
191 security model/framework.
192 But it should hide it to the applications.
194 ## The security framework
196 The implemented security model is the security model of Tizen 3.
197 This model is described [here][tizen-secu-3].
199 The security framework then comes from Tizen 3 but through
203 - **Security-Manager**
205 - **D-Bus** compliant to Cynara.
207 Two patches are applied to the security-manager.
208 The goal of these patches is to remove specific dependencies with Tizen packages that are not needed by AGL.
209 None of these patches adds or removes any behaviour.
211 **In theory, the security framework/model is an implementation details
212 that should not impact the layers above the application framework**.
214 The security framework of Tizen provides "nice lad" a valuable component to
215 scan log files and analyse auditing.
216 This component is still in development.
218 ## The application framework
220 The application framework on top of the security framework
221 provides the components to install and uninstall applications
222 and to run it in a secured environment.
224 The goal is to manage applications and to hide the details of
225 the security framework to the applications.
227 For the reasons explained in introduction, we did not used the
228 application framework of Tizen as is but used an adaptation of it.
230 The basis is kept identical:
232 - The applications are distributed in a digitally signed container that must
233 match the specifications of widgets (web applications).
235 This is described by the technical recommendations [widgets] and
236 [widgets-digsig] of the W3 consortium.
240 - The distribution of HTML, QML and binary applications.
241 - The management of signatures of the widget packages.
243 This basis is not meant as being rigid and it can be extended in the
244 future to include for example incremental delivery.
246 [meta-intel]: https://github.com/01org/meta-intel-iot-security "A collection of layers providing security technologies"
247 [widgets]: http://www.w3.org/TR/widgets "Packaged Web Apps"
248 [widgets-digsig]: http://www.w3.org/TR/widgets-digsig "XML Digital Signatures for Widgets"
249 [libxml2]: http://xmlsoft.org/html/index.html "libxml2"
250 [openssl]: https://www.openssl.org "OpenSSL"
251 [xmlsec]: https://www.aleksey.com/xmlsec "XMLSec"
252 [json-c]: https://github.com/json-c/json-c "JSON-c"
253 [d-bus]: http://www.freedesktop.org/wiki/Software/dbus "D-Bus"
254 [libzip]: http://www.nih.at/libzip "libzip"
255 [cmake]: https://cmake.org "CMake"
256 [security-manager]: https://wiki.tizen.org/wiki/Security/Tizen_3.X_Security_Manager "Security-Manager"
257 [app-manifest]: http://www.w3.org/TR/appmanifest "Web App Manifest"
258 [tizen-security]: https://wiki.tizen.org/wiki/Security "Tizen security home page"
259 [tizen-secu-3]: https://wiki.tizen.org/wiki/Security/Tizen_3.X_Overview "Tizen 3 security overview"
260 [AppFW-APP_install_sequences]: images/AppFW-APP_install_sequences.svg
261 [Security_model_history]: images/Security_model_history.svg