- ***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***.
The main scheme for compiling the project is:
> cmake .
->
+>
> make
->
+>
> sudo make install
By default, the installation is made in ***/usr***.
> 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
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.
### 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.
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.
#### 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
#### 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).
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
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.
## 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.
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
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.
![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.
**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
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.
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.
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.
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
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.
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:
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>
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]
* **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
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.
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
**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
Code Review / src / app-framework-main.git / commitdiff