diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/overview.md | 25 | ||||
| -rw-r--r-- | docs/permissions.md | 16 | ||||
| -rw-r--r-- | docs/quick-tutorial.md | 36 |
3 files changed, 39 insertions, 38 deletions
diff --git a/docs/overview.md b/docs/overview.md index c3627bc..f0441da 100644 --- a/docs/overview.md +++ b/docs/overview.md @@ -43,7 +43,7 @@ of Tizen showed that their dependencies to Tizen are light (and since some of our work, there is no more dependency to tizen). Those components are **cynara**, **security-manager**, **D-Bus aware of cynara**. -Luckyly, these core security components of Tizen are provided +Luckily, these core security components of Tizen are provided by [meta-intel-iot-security][meta-intel], a set of yocto layers. These layers were created by Intel to isolate Tizen specific security components from the initial port of Tizen to Yocto. @@ -57,12 +57,12 @@ The figure below shows the history of these layers. ![Security_model_history][Security_model_history] -We took the decision to use these security layers that provides the +We took the decision to use these security layers that provide the basis of the Tizen security, the security framework. For the components of the application framework, built top of the security framework, instead of pulling the huge set of packages -from Tizen, we decided to refit it by developping a tiny set of +from Tizen, we decided to refit it by developing a tiny set of components that would implement the same behaviour but without all the dependencies and with minor architectural improvements for AGL. @@ -104,7 +104,7 @@ Let follow the sequence of calls: **afm-system-daemon** checks the application to install, its signatures and rights and install it. -5. **afm-system-daemon** calls **SECURITY-MANAGER** for fullfilling +5. **afm-system-daemon** calls **SECURITY-MANAGER** for fulfilling security context of the installed application. 6. **SECURITY-MANAGER** calls **CYNARA** to install initial permissions @@ -124,7 +124,7 @@ Let follow the sequence of calls: or not to start the OTHER application **CYNARA**. 12. **afm-user-daemon** uses **SECURITY-MANAGER** features to set - the seciruty context for the OTHER application. + the security context for the OTHER application. 13. **afm-user-daemon** launches the OTHER application. @@ -161,7 +161,7 @@ Links between the "Security framework" and the "Application framework" The security framework refers to the security model used to ensure security and to the tools that are provided for implementing that model. -The security model refers to how DAC (Discretionnary Access Control), +The security model refers to how DAC (Discretionary Access Control), MAC (Mandatory Access Control) and Capabilities are used by the system to ensure security and privacy. It also includes features of reporting using audit features and by managing logs and alerts. @@ -173,7 +173,7 @@ The application framework uses the security model/framework to ensure the security and the privacy of the applications that it manages. -The application framework must be compliant with the underlyiong +The application framework must be compliant with the underlying security model/framework. But it should hide it to the applications. @@ -188,15 +188,16 @@ the [meta-intel]. It includes: **Security-Manager**, **Cynara** and **D-Bus** compliant to Cynara. -Two patches are applied to the security-manager. These patches are removing -dependencies to packages specific of Tizen but that are not needed by AGL. +Two patches are applied to the security-manager. The goal of these patches +is to remove specific dependencies with Tizen packages that are not needed +by AGL. None of these patches adds or removes any behaviour. -**Theoritically, the security framework/model is an implementation details +**In theory, the security framework/model is an implementation details that should not impact the layers above the application framework**. The security framework of Tizen provides "nice lad" a valuable component to -scan log files and analyse auditing. This component is still in developement. +scan log files and analyse auditing. This component is still in development. The application framework @@ -221,7 +222,7 @@ This model allows the distribution of HTML, QML and binary applications. The management of signatures of the widget packages. This basis is not meant as being rigid and it can be extended in the -futur to include for example incremental delivery. +future to include for example incremental delivery. diff --git a/docs/permissions.md b/docs/permissions.md index 434744e..407fdc2 100644 --- a/docs/permissions.md +++ b/docs/permissions.md @@ -7,10 +7,10 @@ Permission's names The proposal here is to specify a naming scheme for permissions that allows the system to be as stateless as possible. The current -current specification includes in the naming of permissions either +specification includes in the naming of permissions either the name of the bound binding when existing and the level of the permission itself. Doing this, there is no real need for the -framework to keep updated a database of installed permissions. +framework to keep installed permissions in a database. The permission names are [URN][URN] of the form: @@ -22,23 +22,23 @@ AGL (note: a RFC should be produced to standardize this name space). The permission names are made of NSS (the namespace specific string) starting with "permission:" and followed by colon separated fields. The 2 first fields are <api> and <level> and the remaining -fields are gouped to form the <hierarchical-name>. +fields are grouped to form the <hierarchical-name>. <api> ::= [ <pname> ] - + <pname> ::= 1*<pchars> - + <pchars> ::= <upper> | <lower> | <number> | <extra> - + <extra> ::= "-" | "." | "_" | "@" The field <api> can be made of any valid character for NSS except -the characters colon and star (:*). This field designate the api +the characters colon and star (:*). This field designates the api providing the permission. This scheme is used to deduce binding requirements from permission requirements. The field <api> can be the empty string when the permission is defined by the AGL system itself. The field <api> if starting with the character "@" represents -a transversal permission not bound to any binding. +a transversal/cross permission not bound to any binding. <level> ::= 1*<lower> diff --git a/docs/quick-tutorial.md b/docs/quick-tutorial.md index 29e1029..5fc07f1 100644 --- a/docs/quick-tutorial.md +++ b/docs/quick-tutorial.md @@ -4,9 +4,9 @@ AGL Application Framework: A Quick Tutorial Introduction ------------ -This document proposes a quick tutorial to demonstrate the major functionnalities of the AGL Application Framework. For more complete information, please refer to the inline documentation available in the main git repository: +This document proposes a quick tutorial to demonstrate the major functionalities of the AGL Application Framework. For more complete information, please refer to the inline documentation available in the main git repository: -[https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/app-framework-main] +[https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/app-framework-main] [https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/app-framework-binder] @@ -50,42 +50,42 @@ We can see that there are two daemons running: * **afm-system-daemon** runs with a system user 'afm' and is responsible for installing/uninstalling packages * **afm-user-daemon** runs as a user daemon (currently as root because it's the only real user on the target board) and is responsible for the whole lifecycle of the applications running inside the user session. -The application framework has a tool running on the Command Line Interface (CLI). Using the **afm-util** command, you can install, uninstall, list, run, pause ... applications. +The application framework has a tool running on the Command Line Interface (CLI). Using the **afm-util** command, you can install, uninstall, list, run, pause ... applications. To begin, run '**afm-util help**' to get a quick help on commands: root@porter:~# afm-util help usage: afm-util command [arg] - + The commands are: - + list runnables list the runnable widgets installed - + add wgt install wgt install the wgt file - + remove id uninstall id remove the installed widget of id - + info id detail id print detail about the installed widget of id - + ps runners list the running instance - + run id start id start an instance of the widget of id - + kill rid terminate rid terminate the running instance rid - + stop rid pause rid pause the running instance rid - + resume rid continue rid resume the previously rid - + status rid state rid get status of the running instance rid @@ -93,12 +93,12 @@ To begin, run '**afm-util help**' to get a quick help on commands: You can then install your first application: - root@porter:~# afm-util install /home/root/annex.wgt + root@porter:~# afm-util install /home/root/annex.wgt { "added": "webapps-annex@0.0" } Let's install a second application: - root@porter:~# afm-util install /home/root/memory-match.wgt + root@porter:~# afm-util install /home/root/memory-match.wgt { "added": "webapps-memory-match@1.1" } Note that usually, **afm-util** will return a **JSON result**, which is the common format for messages returned by the Application Framework daemons. @@ -154,7 +154,7 @@ To pause the application that was just started (the one with RUNID 1), just run root@porter:~# afm-util terminate 1 true - + The application is now paused, as confirmed by a list of running apps: root@porter:~# afm-util ps @@ -177,7 +177,7 @@ afm-client: a sample HTML5 'Homescreen' **afm-client** is a HTML5 UI that allows to install/uninstall applications as well as starting/pausing them as already demonstrated with afm-util. -The HTML5 UI is accessible remotely through this URL: +The HTML5 UI is accessible remotely through this URL: http://[board_ip]:1234/opa?token=132456789 ### Installing an application |