diff options
| -rw-r--r-- | README.md | 54 | ||||
| -rw-r--r-- | docs/overview.md | 25 | ||||
| -rw-r--r-- | docs/permissions.md | 16 | ||||
| -rw-r--r-- | docs/quick-tutorial.md | 36 |
4 files changed, 66 insertions, 65 deletions
@@ -24,7 +24,7 @@ This package requires the following libraries or modules: - ***dbus-1*** - ***security-manager*** -This package also requires either ***libzip*** (version >= 0.11) +This package also requires either ***libzip*** (version >= 0.11) or the binaries ***zip*** and ***unzip***. By default, it will use ***libzip***. @@ -33,9 +33,9 @@ use ***libzip***. The main scheme for compiling the project is: > cmake . -> +> > make -> +> > sudo make install By default, the installation is made in ***/usr***. @@ -44,7 +44,7 @@ CMAKE_INSTALL_PREFIX as in the below example: > cmake -DCMAKE_INSTALL_PREFIX=/some/where . -You could check the documentation of the standard CMake module +You could check the documentation of the standard CMake module [GNUInstallDirs](https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html). To forbid the use of ***libzip*** and replace it with the @@ -72,7 +72,7 @@ The installed programs are: It runs on the user session bus. - ***wgtpkg-info***: command line tool to display - informations about a widget file. + information about a widget file. - ***wgtpkg-installer***: command line tool to install a widget file. @@ -88,7 +88,7 @@ The installed programs are: ### Actors The framework defined by afm-main is defining several actors: -the platform designer, the application developper, the distributor, +the platform designer, the application developer, the distributor, the user, the hacker. The platform designer defines the AGL system and its security. @@ -101,12 +101,12 @@ The hacker is a user that also develops application for tuning its system. The distributor is the mediator between the developer and the -user. It provides +user. It provides The user is either the driver or a passenger of the car. The application, libraries, services are available on the -platform. Somme of it are in direct interaction with users. +platform. Some of them are in direct interaction with users. Some others, like services, are used indirectly. @@ -115,24 +115,24 @@ Some others, like services, are used indirectly. #### Writing applications The application will receive an identifier. -That identifier must be must have the following feature: +That identifier must have the following feature: -- it must be unic to identify the application and its revisions +- it must be unique to identify the application and its revisions - it should be short enough to be used with efficiency by security components of the system - it can not be stolen by malicious applications that - would like to usurpate the application identity + would like to spoof the application identity - it can be sold to other company The framework provide a facility to create an asymetric key that will serve all the above purposes (it currently -doen't). +doesn't). -Using its favorite environment, the developper -produce applications for the target. +Using its favorite environment, the developer +produces applications for the target. Depending on its constraints either economic, -technical or human, the developer choose the language +technical or human, the developer chooses the language and the environment for developing the applications. This step needs to test and to debug the application on @@ -146,22 +146,22 @@ The framework will provide facilities for debugging #### Packaging applications -Currently the frame work expect widgets packaged as +Currently the framework expects widgets packaged as specified by [Packaged Web Apps](http://www.w3.org/TR/widgets). -When the application is ready, the developper +When the application is ready, the developer creates a package for it. The creation of the package is made of few steps: -- isolate the strict necessarily files and structure it +- isolate the strict necessarily files and structure it to be children of only one root directory -- sign the application with the developper key +- sign the application with the developer key - sign the application with its application key - pack the application using zip The framework will provide facilities to package applications. -Parts of the job can be made with tools provided by afm-main: +Parts of the job can be done with tools provided by afm-main: - ***wgtpkg-sign*** is used to add signatures at root of the package - ***wgtpkg-pack*** is used to create the package file (with wgt extension). @@ -180,14 +180,14 @@ applications. For example, a critical application nested in the system should have high level permissions allowing it to do things that should normally not be done (changing system configuration for example). -To allow such an application, the distributor must sign +To allow such application, the distributor must sign it using its secret private key that will unlock the requested level of permissions. -Currently, the frammework allows to make these steps by hand -the programs ***unzip***, ***wgtpkg-sign*** and ***wgtpkg-pack***. +Currently, the framework allows to make these steps manually +using ***unzip***, ***wgtpkg-sign*** and ***wgtpkg-pack*** utilities. -The applications of the store will then be available +Applications of the store will then be available for browsing and searching over HTTP/Internet. #### Installing applications @@ -196,7 +196,7 @@ The framework will provide an API for downloading and installing an application from stores (it currently doesn't). The current version of afm allows to install widgets -from local files (either preinstalled or downloaded). +from local files (either pre-installed or downloaded). To install a widget, you can use either the program ***wgtpkg-installer*** while being the framework user. @@ -229,7 +229,7 @@ TO BE CONTINUED ## Extension to the packaging specifications -The widgets are specified in that W3C recommandation: +The widgets are specified in that W3C recommendation: [Packaged Web Apps](http://www.w3.org/TR/widgets). This model was initially designed for HTML applications. But it is well suited for other kind of applications. @@ -244,7 +244,7 @@ nor suited for managing privileges: However, it may become of actuallity in some future. The main idea is to use the file ***config.xml*** as a switch -for several contants. +for several constants. The current specifications for ***config.xml*** are allowing to describe either HTML5, QML and native applications. Using *feature*, it is also possible to define uses of 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 |