Import from docs-agl/docs

Change-Id: Id524561d87410e5463cddd123b30eb63d75b62bd
Signed-off-by: Stephane Desneux <stephane.desneux@iot.bzh>

9 files changed, 859 insertions, 0 deletions

diff --git a/docs/security-blueprint/part-5/0_Abstract.md b/docs/security-blueprint/part-5/0_Abstract.md
new file mode 100644
index 0000000..ddf7d2a
--- /dev/null
+++ b/docs/security-blueprint/part-5/0_Abstract.md
@@ -0,0 +1,103 @@
+# Part 5 - Platform
+
+## Abstract
+
+The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services.
+The platform includes the following software:
+
+- Linux **BSP** configured for reference boards.
+- Proprietary device drivers for common peripherals on reference boards.
+- Application framework.
+- Windows/layer management (graphics).
+- Sound resource management.
+- An atomic software update system (chapter Update).
+- Building and debug tools (based on Yocto project).
+
+<!-- section-todo -->
+
+Domain              | Improvement
+------------------- | --------------------------------
+Platform-Abstract-1 | Create a graphics and sound part.
+
+<!-- end-section-todo -->
+
+This part focuses on the AGL platform including all tools and techniques used to
+upgrade the security and downgrade the danger. It must be possible to apply the
+two fundamental principles written at the very beginning of the document. First
+of all, security management must remain simple. You must also prohibit
+everything by default, and then define a set of authorization rules. As cases
+to deal with, we must:
+
+- Implement a **MAC** for processes and files.
+- Limit communication between applications (_SystemBus_ and _SystemD_ part).
+- Prohibit all tools used during development mode (_Utilities_ and _Services_ part).
+- Manage user capabilities (_Users_ part).
+- Manage application permissions and policies (_AGLFw_ part).
+
+<!-- section-note -->
+
+The tools and concepts used to meet these needs are only examples.
+Any other tool that meets the need can be used.
+
+<!-- end-section-note -->
+
+In AGL, as in many other embedded systems, different security mechanisms settle
+in the core layers to ensure isolation and data privacy. While the Mandatory
+Access Control layer (**SMACK**) provides global security and isolation, other
+mechanisms like **Cynara** are required to check application's permissions at
+runtime. Applicative permissions (also called "_privileges_") may vary depending
+on the user and the application being run: an application should have access to
+a given service only if it is run by the proper user and if the appropriate
+permissions are granted.
+
+## Discretionary Access Control
+
+**D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux method of separating
+users and groups from one another. In a shared environment where multiple users
+have access to a computer or network, Unix IDs have offered a way to contain access
+within privilege areas for individuals, or shared among the group or system.
+The Android system took this one step further, assigning new user IDs for each App.
+This was never the original intention of Linux UIDs, but was able to provide
+Android’s initial security element: the ability to sandbox applications.
+
+Although AGL mentions use of **DAC** for security isolation, the weight of the
+security responsibility lies in the **M**andatory **A**ccess **C**ontrol (**MAC**) and **Cynara**.
+Furthermore, there are system services with unique UIDs. however,the system
+does not go to the extreme of Android, where every application has its own UID.
+All sandboxing (app isolation) in AGL is handled in the **MAC** contexts.
+
+## Mandatory Access Control
+
+**M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**,
+whereby extended attributes (xattr) are associated with the filesystem.
+In the case of AGL, the smackfs filesystem allows files and directories
+to be associated with a SMACK label, providing the ability of further
+discrimination on access control. A SMACK label is a simple null terminated
+character string with a maximum of 255 bytes. While it doesn’t offer the
+richness of an SELinux label, which provides a user, role,type, and level,
+the simplicity of a single value makes the overall design far less complex.
+There is arguably less chance of the security author making mistakes in the policies set forth.
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Acronyms and Abbreviations
+
+The following table lists the terms utilized within this part of the document.
+
+Acronyms or Abbreviations | Description
+------------------------- | --------------------------------------------------------------
+_ACL_                     | **A**ccess **C**ontrol **L**ists
+_alsa_                    | **A**dvanced **L**inux **S**ound **A**rchitecture
+_API_                     | **A**pplication **P**rogramming **I**nterface
+_AppFw_                   | **App**lication **F**rame**w**ork
+_BSP_                     | **B**oard **S**upport **P**ackage
+_Cap_                     | **Cap**abilities
+_DAC_                     | **D**iscretionary **A**ccess **C**ontrol
+_DDOS_                    | **D**istributed **D**enial **O**f **S**ervice
+_DOS_                     | **D**enial **O**f **S**ervice
+_IPC_                     | **I**nter-**P**rocess **C**ommunication
+_MAC_                     | **M**andatory **A**ccess **C**ontrol
+_PAM_                     | **P**luggable **A**uthentication **M**odules
+_SMACK_                   | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel
diff --git a/docs/security-blueprint/part-5/1-MAC.md b/docs/security-blueprint/part-5/1-MAC.md
new file mode 100644
index 0000000..73543e9
--- /dev/null
+++ b/docs/security-blueprint/part-5/1-MAC.md
@@ -0,0 +1,165 @@
+# Mandatory Access Control
+
+<!-- section-note -->
+
+We decided to put the **MAC** protection on the platform part despite the fact
+that it applies to the kernel too, since its use will be mainly at the platform
+level (except floor part).
+
+<!-- end-section-note -->
+
+**M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the
+Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL
+uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol
+**K**ernel (**SMACK**). This protection involves the creation of **SMACK**
+labels as part of the extended attributes **SMACK** labels to the file extended
+attributes. And a policy is also created to define the behaviour of each label.
+
+The kernel access controls is based on these labels and this policy. If there
+is no rule, no access will be granted and as a consequence, what is not
+explicitly authorized is forbidden.
+
+There are two types of **SMACK** labels:
+
+- **Execution SMACK** (Attached to the process): Defines how files are
+  _accessed_ and _created_ by that process.
+- **File Access SMACK** (Written to the extended attribute of the file): Defines
+  _which_ process can access the file.
+
+By default a process executes with its File Access **SMACK** label unless an
+Execution **SMACK** label is defined.
+
+AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System
+into the following domains:
+
+- Floor.
+- System.
+- Applications, Services and User.
+
+See [AGL security framework review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) and [Smack White Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf)
+for more information.
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Floor
+
+The _floor_ domain includes the base system services and any associated data and
+libraries. This data remains unchanged at runtime. Writing to floor files or
+directories is allowed only in development mode or during software installation
+or upgrade.
+
+The following table details the _floor_ domain:
+
+Label | Name  | Execution **SMACK** | File Access **SMACK**
+----- | ----- | ------------------- | ---------------------------------------
+`-`   | Floor | `r-x` for all       | Only kernel and internal kernel thread.
+`^`   | Hat   | `---` for all       | `rx` on all domains.
+`*`   | Star  | `rwx` for all       | None
+
+<!-- section-note -->
+
+- The Hat label is Only for privileged system services (currently only
+  systemd-journal). Useful for backup or virus scans. No file with this label
+  should exist except in the debug log.
+
+- The Star label is used for device files or `/tmp` Access restriction managed
+  via **DAC**. Individual files remain protected by their **SMACK** label.
+
+<!-- end-section-note --> <!-- section-config -->
+
+Domain             | `Label` name | Recommendations
+------------------ | ------------ | -----------------------------------------------------------
+Kernel-MAC-Floor-1 | `^`          | Only for privileged system services.
+Kernel-MAC-Floor-2 | `*`          | Used for device files or `/tmp` Access restriction via DAC.
+
+<!-- end-section-config -->
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## System
+
+The _system_ domain includes a reduced set of core system services of the OS and
+any associated data. This data may change at runtime.
+
+The following table details the _system_ domain:
+
+Label            | Name      | Execution **SMACK**                             | File Access **SMACK**
+---------------- | --------- | ----------------------------------------------- | ---------------------
+`System`         | System    | None                                            | Privileged processes
+`System::Run`    | Run       | `rwxatl` for User and System label              | None
+`System::Shared` | Shared    | `rwxatl` for system domain `r-x` for User label | None
+`System::Log`    | Log       | `rwa` for System label `xa` for user label      | None
+`System::Sub`    | SubSystem | Subsystem Config files                          | SubSystem only
+
+<!-- section-config -->
+
+Domain              | `Label` name     | Recommendations
+------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------
+Kernel-MAC-System-1 | `System`         | Process should write only to file with transmute attribute.
+Kernel-MAC-System-2 | `System::run`    | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`.
+Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege.
+Kernel-MAC-System-4 | `System::Log`    | Some limitation may impose to add `w` to enable append.
+Kernel-MAC-System-5 | `System::Sub`    | Isolation of risky Subsystem.
+
+<!-- end-section-config -->
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Applications, Services and User
+
+The _application_, _services_ and _user_ domain includes code that provides
+services to the system and user, as well as any associated data. All code
+running on this domain is under _Cynara_ control.
+
+The following table details the _application_, _services_ and _user_ domain:
+
+Label               | Name   | Execution **SMACK**                                                         | File Access **SMACK**
+------------------- | ------ | --------------------------------------------------------------------------- | ---------------------------
+`User::Pkg::$AppID` | AppID  | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App
+`User::Home`        | Home   | `rwx-t` from System label `r-x-l` from App                                  | None
+`User::App-Shared`  | Shared | `rwxat` from System and User domains label of $User                         | None
+
+<!-- section-config -->
+
+Domain              | `Label` name        | Recommendations
+------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------
+Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode.
+Kernel-MAC-System-2 | `User::Home`        | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute.
+Kernel-MAC-System-3 | `User::App-Shared`  | Shared space between all App running for a given user.
+
+<!-- end-section-config -->
+
+## Attack Vectors
+
+There are 4 major components to the system:
+
+- The LSM kernel module.
+- The `smackfs` filesystem.
+- Basic utilities for policy management and checking.
+- The policy/configuration data.
+
+As with any mandatory access system, the policy management needs to be carefully separated
+from the checking, as the management utilities can become a convenient point of attack.
+Dynamic additions to the policy system need to be carefully verified, as the ability to
+update the policies is often needed, but introduces a possible threat. Finally,
+even if the policy management is well secured, the policy checking and failure response
+to that checking is also of vital importance to the smooth operation of the system.
+
+While **MAC** is a certainly a step up in security when compared to DAC, there are still
+many ways to compromise a SMACK-enabled Linux system. Some of these ways are as follows:
+
+- Disabling SMACK at invocation of the kernel (with command-line: security=none).
+- Disabling SMACK in the kernel build and redeploying the kernel.
+- Changing a SMACK attribute of a file or directory at install time.
+- Tampering with a process with the CAP_MAC_ADMIN privilege.
+- Setting/Re-setting the SMACK label of a file.
+- Tampering with the default domains (i.e. /etc/smack/accesses.d/default-access-domains).
+- Disabling or tampering with the SMACK filesystem (i.e. /smackfs).
+- Adding policies with `smackload` (adding the utility if not present).
+- Changing labels with `chsmack` (adding the utility if not present).
diff --git a/docs/security-blueprint/part-5/2-SystemD.md b/docs/security-blueprint/part-5/2-SystemD.md
new file mode 100644
index 0000000..35abe16
--- /dev/null
+++ b/docs/security-blueprint/part-5/2-SystemD.md
@@ -0,0 +1,60 @@
+# SystemD
+
+`afm-system-daemon` is used to:
+
+- Manage users and user sessions.
+- Setup applications and services (_CGroups_, _namespaces_, autostart, permissions).
+- Use of `libsystemd` for its programs (event management, **D-Bus** interface).
+
+<!-- section-config -->
+
+Domain             | Object         | Recommendations
+------------------ | -------------- | ------------------------------------
+Platform-SystemD-1 | Security model | Use Namespaces for containerization.
+Platform-SystemD-2 | Security model | Use CGroups to organise processes.
+
+<!-- end-section-config -->
+
+See [systemd integration and user management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for more information.
+
+## Benefits
+
+- Removal of one privileged process: **afm-user-daemon**
+- Access and use of high level features:
+
+  - Socket activation.
+  - Management of users and integration of **PAM**.
+  - Dependency resolution to services.
+  - `Cgroups` and resource control.
+  - `Namespaces` containerization.
+  - Autostart of required API.
+  - Permissions and security settings.
+  - Network management.
+
+<!-- pagebreak -->
+
+## CGroups
+
+Control Groups offer a lot of features, with the most useful ones you can
+control: Memory usage, how much CPU time is allocated, how much device I/O is
+allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise
+processes (each service is a _CGroups_, and all processes started by that
+service use that _CGroups_). By default, **SystemD** automatically creates a
+hierarchy of slice, scope and service units to provide a unified structure for
+the _CGroups_ tree. With the `systemctl` command, you can further modify this
+structure by creating custom slices. Currently, in AGL, there are 2 slices
+(**user.slice** and **system.slice**).
+
+## Namespaces
+
+### User side
+
+There are several ways of authenticating users (Key Radio Frequency, Phone,
+Gesture, ...). Each authentication provides dynamic allocation of **uids** to
+authenticated users. **Uids** is used to ensure privacy of users and **SMACK**
+for applications privacy.
+
+First, the user initiates authentication with **PAM** activation. **PAM**
+Standard offers highly configurable authentication with modular design like
+face recognition, Voice identification or with a password. Then users should
+access identity services with services and applications.
diff --git a/docs/security-blueprint/part-5/3-SystemBus.md b/docs/security-blueprint/part-5/3-SystemBus.md
new file mode 100644
index 0000000..e2af387
--- /dev/null
+++ b/docs/security-blueprint/part-5/3-SystemBus.md
@@ -0,0 +1,24 @@
+# D-Bus
+
+D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and
+daemon) that helps applications to talk to each other. The use of D-Bus is great
+because it allows to implement discovery and signaling.
+
+The D-Bus session is by default addressed by environment variable
+`DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable `DBUS_SESSION_BUS_ADDRESS`
+is automatically set for user sessions. D-Bus usage is linked to permissions.
+
+D-Bus has already had several [security issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
+(mostly **DoS** issues), to allow applications to keep talking to each other.
+It is important to protect against this type of attack to keep the system more
+stable.
+
+
+<!-- section-config -->
+
+Domain          | Object         | Recommendations
+--------------- | -------------- | ------------------------------------
+Platform-DBus-1 | Security model | Use D-Bus as IPC.
+Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
+
+<!-- end-section-config -->
diff --git a/docs/security-blueprint/part-5/4-Services.md b/docs/security-blueprint/part-5/4-Services.md
new file mode 100644
index 0000000..013f693
--- /dev/null
+++ b/docs/security-blueprint/part-5/4-Services.md
@@ -0,0 +1,37 @@
+# System services and daemons
+
+<!-- section-todo -->
+
+Domain              | Improvement
+------------------- | -----------
+Platform-Services-1 | SystemD ?
+Platform-Services-2 | Secure daemon ?
+
+<!-- end-section-todo -->
+
+## Tools
+
+- **connman**: An internet connection manager designed to be slim and to use as
+  few resources as possible. It is a fully modular system that can be extended,
+  through plug-ins, to support all kinds of wired or wireless technologies.
+- **bluez** is a Bluetooth stack. Its goal is to program an implementation of
+  the Bluetooth wireless standards specifications. In addition to the basic stack,
+  the `bluez-utils` and `bluez-firmware` packages contain low level utilities such
+  as `dfutool` which can interrogate the Bluetooth adapter chipset in order to
+  determine whether its firmware can be upgraded.
+- **gstreamer** is a pipeline-based multimedia framework. It can be used to build
+  a system that reads files in one format, processes them, and exports them in
+  another format.
+- **alsa** is a software framework and part of the Linux kernel that provides an
+  **API** for sound card device drivers.
+
+<!-- section-config -->
+
+Domain               | `Tool` name | _State_
+-------------------- | ----------- | -------
+Platform-Utilities-1 | `connman`   | _Used_ as a connection manager.
+Platform-Utilities-2 | `bluez`     | _Used_ as a Bluetooth manager.
+Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format.
+Platform-Utilities-4 | `alsa`      | _Used_ to provides an API for sound card device drivers.
+
+<!-- end-section-config -->
diff --git a/docs/security-blueprint/part-5/5-AppFw.md b/docs/security-blueprint/part-5/5-AppFw.md
new file mode 100644
index 0000000..e92a0c6
--- /dev/null
+++ b/docs/security-blueprint/part-5/5-AppFw.md
@@ -0,0 +1,315 @@
+# Application framework/model (**AppFw**)
+
+The AGL application framework consists of several inter-working parts:
+
+- **SMACK**: The kernel level **LSM** (**L**inux **S**ecurity **M**odule) that performs extended access control of the system.
+- **Cynara**: the native gatekeeper daemon used for policy handling, updating to the database and policy checking.
+- Security Manager: a master service, through which all security events are intended to take place.
+- Several native application framework utilities: `afm-main-binding`, `afm-user-daemon`, `afm-system-daemon`.
+
+The application framework manages:
+
+- The applications and services management: Installing, Uninstalling, Listing, ...
+- The life cycle of applications: Start -> (Pause, Resume) -> Stop.
+- Events and signals propagation.
+- Privileges granting and checking.
+- API for interaction with applications.
+
+<!-- section-note -->
+
+- The **security model** refers to the security model used to ensure security
+  and to the tools that are provided for implementing that model. It's an
+  implementation detail that should not impact the layers above the application
+  framework.
+
+- The **security model** refers to how **DAC** (**D**iscretionary **A**ccess **C**ontrol),
+  **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.
+
+<!-- end-section-note -->
+
+The **AppFw** uses the security model to ensure the security and the privacy of
+the applications that it manages. It must be compliant with the underlying
+security model. But it should hide it to the applications.
+
+<!-- section-config -->
+
+Domain                 | Object         | Recommendations
+---------------------- | -------------- | --------------------------------
+Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model.
+
+<!-- end-section-config -->
+
+See [AGL AppFw Privileges Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) and [AGL - Application Framework Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) for more
+information.
+
+<!-- pagebreak -->
+
+The Security Manager communicates policy information to **Cynara**,
+which retains information in its own database in the format of a text
+file with comma-separated values (CSV). There are provisions to retain
+a copy of the CSV text file when the file is being updated.
+
+Runtime checking occurs through **Cynara**. Each application that is
+added to the framework has its own instantiation of a SMACK context
+and D-bus bindings. The afb_daemon and Binder form a web-service that
+is communicated to through http or a websocket from the application-proper.
+This http or websocket interface uses a standard unique web token for API communication.
+
+![Application Framework Flow](App-flow.png)
+
+## Cynara
+
+There's a need for another mechanism responsible for checking applicative
+permissions: Currently in AGL, this task depends on a policy-checker service
+(**Cynara**).
+
+- Stores complex policies in databases.
+- "Soft" security (access is checked by the framework).
+
+Cynara interact with **D-Bus** in order to deliver this information.
+
+Cynara consists of several parts:
+
+- Cynara: a daemon for controlling policies and responding to access control requests.
+- Database: a spot to hold policies.
+- Libraries: several static and dynamic libraries for communicating with Cynara.
+
+The daemon communicates to the libraries over Unix domain sockets.
+The database storage format is a series of CSV-like files with an index file.
+
+There are several ways that an attacker can manipulate policies of the Cynara system:
+
+- Disable Cynara by killing the process.
+- Tamper with the Cynara binary on-disk or in-memory.
+- Corrupt the database controlled by Cynara.
+- Tamper with the database controlled by Cynara.
+- Highjack the communication between Cynara and the database.
+
+The text-based database is the weakest part of the system and although there are some
+consistency mechanisms in place (i.e. the backup guard), these mechanisms are weak at best
+and can be countered by an attacker very easily.
+
+<!-- section-config -->
+
+Domain                  | Object      | Recommendations
+----------------------- | ----------- | -------------------------------------
+Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service.
+
+<!-- end-section-config -->
+
+### Policies
+
+- Policy rules:
+
+  - Are simple - for pair [application context, privilege] there is straight
+    answer (single Policy Type): [ALLOW / DENY / ...].
+  - No code is executed (no script).
+  - Can be easily cached and managed.
+
+- Application context (describes id of the user and the application credentials)
+  It is build of:
+
+  - UID of the user that runs the application.
+  - **SMACK** label of application.
+
+## Holding policies
+
+Policies are kept in buckets. Buckets are set of policies which have additional
+a property of default answer, the default answer is yielded if no policy matches
+searched key. Buckets have names which might be used in policies (for directions).
+
+## Attack Vectors
+
+The following attack vectors are not completely independent. While attackers may
+have varying levels of access to an AGL system, experience has shown that a typical
+attack can start with direct access to a system, find the vulnerabilities,
+then proceed to automate the attack such that it can be invoked from less accessible
+standpoint (e.g. remotely). Therefore, it is important to assess all threat levels,
+and protect the system appropriately understanding that direct access attacks
+are the door-way into remote attacks.
+
+### Remote Attacks
+
+The local web server interface used for applications is the first point of attack,
+as web service APIs are well understood and easily intercepted. The local web server
+could potentially be exploited by redirecting web requests through the local service
+and exploiting the APIs. While there is the use of a security token on the web
+service API, this is weak textual matching at best. This will not be difficult to spoof.
+It is well known that [API Keys do not provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/).
+
+It is likely that the architectural inclusion of an http / web-service interface
+provided the most flexibility for applications to be written natively or in HTML5.
+However, this flexibility may trade-off with security concerns. For example,
+if a native application were linked directly to the underlying framework services,
+there would be fewer concerns over remote attacks coming through the web-service interface.
+
+Leaving the interface as designed, mitigations to attacks could include further
+securing the interface layer with cryptographic protocols:
+e.g. encrypted information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman).
+
+### User-level Native Attacks
+
+- Modifying the CSV data-base
+- Modifying the SQLite DB
+- Tampering with the user-level binaries
+- Tampering with the user daemons
+- Spoofing the D-bus Interface
+- Adding executables/libraries
+
+With direct access to the device, there are many security concerns on the native level.
+For example, as **Cynara** uses a text file data-base with comma-separated values (CSV),
+an attacker could simply modify the data-base to escalate privileges of an application.
+Once a single application has all the privileges possible on the system, exploits can
+come through in this manner. Similarly the SQLite database used by the Security Manager
+is not much different than a simple text file. There are many tools available to add,
+remove, modify entries in an SQLite data-base.
+
+On the next level, a common point of attack is to modify binaries or daemons for exploiting
+functionality. There are many Linux tools available to aid in this regard,
+including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml),
+and [radare2](https://rada.re/r/). With the ability to modify binaries,
+an attacker can do any number of activities including: removing calls to security checks,
+redirecting control to bypass verification functionality, ignoring security policy handling,
+escalating privileges, etc.
+
+Additionally, another attack vector would be to spoof the D-bus interface. D-bus is a
+message passing system built upon Inter-Process Communication (IPC), where structured
+messages are passed based upon a protocol. The interface is generic and well documented.
+Therefore, modifying or adding binaries/libraries to spoof this interface is a relatively
+straight-forward process. Once the interface has been spoofed, the attacker can issue any
+number of commands that lead into control of low-level functionality.
+
+Protecting a system from native attacks requires a methodical approach. First, the system
+should reject processes that are not sanctioned to run. Signature-level verification at
+installation time will help in this regard, but run-time integrity verification is much better.
+Signatures need to originate from authorized parties, which is discussed further
+in a later section on the Application Store.
+
+On the next level, executables should not be allowed to do things where they have not been
+granted permission. DAC and SMACK policies can help in this regard. On the other hand,
+there remain concerns with memory accesses, system calls, and other process activity
+that may go undetected. For this reason, a secure environment which monitors all activity
+can give indication of all unauthorized activity on the system.
+
+Finally, it is very difficult to catch attacks of direct tampering in a system.
+These types of attacks require a defense-in-depth approach, where complementary software
+protection and hardening techniques are needed. Tamper-resistance and anti-reverse-engineering
+technologies include program transformations/obfuscation, integrity verification,
+and white-box cryptography. If applied in a mutually-dependent fashion and considering
+performance/security tradeoffs, the approach can provide an effective barrier
+to direct attacks to the system. Furthermore, the use of threat monitoring provides a
+valuable telemetry/analytics capability and the ability to react and renew a system under attack.
+
+### Root-level Native Attacks
+
+- Tampering the system daemon
+- Tampering Cynara
+- Tampering the security manager
+- Disabling SMACK
+- Tampering the kernel
+
+Once root-level access (i.e. su) has been achieved on the device, there are many ways
+to compromise the system. The system daemon, **Cynara**, and the security manager are
+vulnerable to tampering attacks. For example, an executable can be modified in memory
+to jam a branch, jump to an address, or disregard a check. This can be as simple as replacing
+a branch instruction with a NOP, changing a memory value, or using a debugger (e.g. gdb, IDA)
+to change an instruction. Tampering these executables would mean that policies can be
+ignored and verification checks can be bypassed.
+
+Without going so far as to tamper an executable, the **SMACK** system is also vulnerable to attack.
+For example, if the kernel is stopped and restarted with the *security=none* flag,
+then SMACK is not enabled. Furthermore, `systemd` starts the loading of **SMACK** rules during
+start-up. If this start-up process is interfered with, then **SMACK** will not run.
+Alternatively, new policies can be added with `smackload` allowing unforseen privileges
+to alternative applications/executables.
+
+Another intrusion on the kernel level is to rebuild the kernel (as it is open-source)
+and replace it with a copy that has **SMACK** disabled, or even just the **SMACK** filesystem
+(`smackfs`) disabled. Without the extended label attributes, the **SMACK** system is disabled.
+
+Root-level access to the device has ultimate power, where the entire system can be compromised.
+More so, a system with this level access allows an attacker to craft a simpler *point-attack*
+which can operate on a level requiring fewer privileges (e.g. remote access, user-level access).
+
+## Vulnerable Resources
+
+### Resource: `afm-user-daemon`
+
+The `afm-user-daemon` is in charge of handling applications on behalf of a user. Its main tasks are:
+
+- Enumerate applications that the end user can run and keep this list available on demand.
+- Start applications on behalf of the end user, set user running environment, set user security context.
+- List current runnable or running applications.
+- Stop (aka pause), continue (aka resume), terminate a running instance of a given application.
+- Transfer requests for installation/uninstallation of applications to the corresponding system daemon afm-system-daemon.
+
+The `afm-user-daemon` launches applications. It builds a secure environment for the application
+before starting it within that environment. Different kinds of applications can be launched,
+based on a configuration file that describes how to launch an application of a given kind within
+a given launching mode: local or remote. Launching an application locally means that
+the application and its binder are launched together. Launching an application remotely
+translates in only launching the application binder.
+
+The UI by itself has to be activated remotely by a request (i.e. HTML5 homescreen in a browser).
+Once launched, running instances of the application receive a `runid` that identifies them.
+`afm-user-daemon` manages the list of applications that it has launched.
+When owning the right permissions, a client can get the list of running instances and details
+about a specific running instance. It can also terminate, stop or continue a given application.
+If the client owns the right permissions, `afm-user-daemon` delegates the task of
+installing and uninstalling applications to `afm-system-daemon`.
+
+`afm-user-daemon` is launched as a `systemd` service attached to a user session.
+Normally, the service file is located at /usr/lib/systemd/user/afm-user-daemon.service.
+
+Attacker goals:
+
+- Disable `afm-user-daemon`.
+- Tamper with the `afm-user-daemon` configuration.
+  - /usr/lib/systemd/user/afm-user-daemon.service.
+  - Application(widget) config.xml file.
+  - /etc/afm/afm-launch.conf (launcher configuration).
+
+- Escalate user privileges to gain more access with `afm-user-daemon`.
+- Install malicious application (widget).
+- Tamper with `afm-user-daemon` on disk or in memory.
+
+### Resource: `afm-system-daemon`
+
+The `afm-system-daemon` is in charge of installing applications on the AGL system. Its main tasks are:
+
+- Install applications and setup security framework for newly installed applications.
+- Uninstall applications.
+
+`afm-system-daemon` is launched as a `systemd` service attached to system. Normally,
+the service file is located at /lib/systemd/system/afm-systemdaemon.service.
+
+Attacker goals:
+
+- Disable `afm-system-daemon`.
+- Tamper with the `afm-system-daemon` configuration.
+- Tamper `afm-system-daemon` on disk or in memory.
+
+### Resource `afb-daemon`
+
+`afb-binder` is in charge of serving resources and features through an HTTP interface.
+`afb-daemon` is in charge of binding one instance of an application to the AGL framework
+and AGL system. The application and its companion binder run in a secured and isolated
+environment set for them. Applications are intended to access to AGL system through the binder.
+`afb-daemon` binders serve files through HTTP protocol and offers developers the capability
+to expose application API methods through HTTP or WebSocket protocol.
+
+Binder bindings are used to add APIs to `afb-daemon`. The user can write a binding for `afb-daemon`.
+The binder `afb-daemon` serves multiple purposes:
+
+1. It acts as a gateway for the application to access the system.
+2. It acts as an HTTP server for serving files to HTML5 applications.
+3. It allows HTML5 applications to have native extensions subject to security enforcement for accessing hardware resources or for speeding up parts of algorithm.
+
+Attacker goals:
+
+- Break from isolation.
+- Disable `afb-daemon`.
+- Tamper `afb-demon` on disk or in memory.
+- Tamper **capabilities** by creating/installing custom bindings for `afb-daemon`.
\ No newline at end of file
diff --git a/docs/security-blueprint/part-5/6-Utilities.md b/docs/security-blueprint/part-5/6-Utilities.md
new file mode 100644
index 0000000..309cbc4
--- /dev/null
+++ b/docs/security-blueprint/part-5/6-Utilities.md
@@ -0,0 +1,78 @@
+# Utilities
+
+- **busybox**: Software that provides several stripped-down Unix tools in a
+  single executable file. Of course, it will be necessary to use a "production"
+  version of **busybox** in order to avoid all the tools useful only in
+  development mode.
+
+<!-- section-config -->
+
+Domain               | `Tool` name | _State_
+-------------------- | ----------- | ----------------------------------------------------------------------
+Platform-Utilities-1 | `busybox`   | _Used_ to provide a number of tools. Do not compile development tools.
+
+<!-- end-section-config -->
+
+## Functionalities to exclude in production mode
+
+In production mode, a number of tools must be disabled to prevent an attacker
+from finding logs for example. This is useful to limit the visible surface and
+thus complicate the fault finding process. The tools used only in development
+mode are marked by an '**agl-devel**' feature. When building in production mode,
+these tools will not be compiled.
+
+<!-- section-config -->
+
+Domain                | `Utility` name and normal `path`                     | _State_
+--------------------- | ---------------------------------------------------- | ----------
+Platform-Utilities-1  | `chgrp` in `/bin/chgrp`                              | _Disabled_
+Platform-Utilities-2  | `chmod` in `/bin/chmod`                              | _Disabled_
+Platform-Utilities-3  | `chown` in `/bin/chown`                              | _Disabled_
+Platform-Utilities-4  | `dmesg` in `/bin/dmesg`                              | _Disabled_
+Platform-Utilities-5  | `Dnsdomainname` in `/bin/dnsdomainname`              | _Disabled_
+Platform-Utilities-6  | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_
+Platform-Utilities-7  | `Editors` in (vi) `/bin/vi`                          | _Disabled_
+Platform-Utilities-8  | `find` in `/bin/find`                                | _Disabled_
+Platform-Utilities-9  | `gdbserver` in `/bin/gdbserver`                      | _Disabled_
+Platform-Utilities-10 | `hexdump` in `/bin/hexdump`                          | _Disabled_
+Platform-Utilities-11 | `hostname` in `/bin/hostname`                        | _Disabled_
+Platform-Utilities-12 | `install` in `/bin/install`                          | _Disabled_
+Platform-Utilities-13 | `iostat` in `/bin/iostat`                            | _Disabled_
+Platform-Utilities-14 | `killall` in `/bin/killall`                          | _Disabled_
+Platform-Utilities-15 | `klogd` in `/sbin/klogd`                             | _Disabled_
+Platform-Utilities-16 | `logger` in `/bin/logger`                            | _Disabled_
+Platform-Utilities-17 | `lsmod` in `/sbin/lsmod`                             | _Disabled_
+Platform-Utilities-18 | `pmap` in `/bin/pmap`                                | _Disabled_
+Platform-Utilities-19 | `ps` in `/bin/ps`                                    | _Disabled_
+Platform-Utilities-20 | `ps` in `/bin/ps`                                    | _Disabled_
+Platform-Utilities-21 | `rpm` in `/bin/rpm`                                  | _Disabled_
+Platform-Utilities-22 | `SSH`                                                | _Disabled_
+Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug`                   | _Disabled_
+Platform-Utilities-24 | `strace` in `/bin/trace`                             | _Disabled_
+Platform-Utilities-25 | `su` in `/bin/su`                                    | _Disabled_
+Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger`                  | _Disabled_
+Platform-Utilities-27 | `top` in `/bin/top`                                  | _Disabled_
+Platform-Utilities-28 | `UART` in `/proc/tty/driver/`                        | _Disabled_
+Platform-Utilities-29 | `which` in `/bin/which`                              | _Disabled_
+Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami`                  | _Disabled_
+Platform-Utilities-31 | `awk` (busybox)                                      | _Enabled_
+Platform-Utilities-32 | `cut` (busybox)                                      | _Enabled_
+Platform-Utilities-33 | `df` (busybox)                                       | _Enabled_
+Platform-Utilities-34 | `echo` (busybox)                                     | _Enabled_
+Platform-Utilities-35 | `fdisk` (busybox)                                    | _Enabled_
+Platform-Utilities-36 | `grep` (busybox)                                     | _Enabled_
+Platform-Utilities-37 | `mkdir` (busybox)                                    | _Enabled_
+Platform-Utilities-38 | `mount` (vfat) (busybox)                             | _Enabled_
+Platform-Utilities-39 | `printf` (busybox)                                   | _Enabled_
+Platform-Utilities-40 | `sed` in `/bin/sed` (busybox)                        | _Enabled_
+Platform-Utilities-41 | `tail` (busybox)                                     | _Enabled_
+Platform-Utilities-42 | `tee` (busybox)                                      | _Enabled_
+Platform-Utilities-43 | `test` (busybox)                                     | _Enabled_
+
+<!-- end-section-config --> <!-- section-note -->
+
+The _Enabled_ Unix/Linux utilities above shall be permitted as they are often
+used in the start-up scripts and for USB logging. If any of these utilities are
+not required by the device then those should be removed.
+
+<!-- end-section-note -->
diff --git a/docs/security-blueprint/part-5/7-Users.md b/docs/security-blueprint/part-5/7-Users.md
new file mode 100644
index 0000000..af5a686
--- /dev/null
+++ b/docs/security-blueprint/part-5/7-Users.md
@@ -0,0 +1,77 @@
+# Users
+
+The user policy can group users by function within the car. For example, we can
+consider a driver and his passengers. Each user is assigned to a single group to
+simplify the management of space security.
+
+## Root Access
+
+The main applications, those that provide the principal functionality of the
+embedded device, should not execute with root identity or any capability.
+
+If the main application is allowed to execute at any capability, then the entire
+system is at the mercy of the said application's good behaviour. Problems arise
+when an application is compromised and able to execute commands which could
+consistently and persistently compromise the system by implanting rogue
+applications.
+
+It is suggested that the middleware and the UI should run in a context on a user
+with no capability and all persistent resources should be maintained without any
+capability.
+
+One way to ensure this is by implementing a server-client paradigm. Services
+provided by the system's drivers can be shared this way. The other advantage of
+this approach is that multiple applications can share the same resources at the
+same time.
+
+<!-- section-config -->
+
+Domain                | Object           | Recommendations
+--------------------- | ---------------- | -----------------------------------------------------
+Platform-Users-root-1 | Main application | Should not execute as root.
+Platform-Users-root-2 | UI               | Should run in a context on a user with no capability.
+
+<!-- end-section-config -->
+
+Root access should not be allowed for the following utilities:
+
+<!-- section-config -->
+
+Domain                | `Utility` name | _State_
+--------------------- | -------------- | -------------
+Platform-Users-root-3 | `login`        | _Not allowed_
+Platform-Users-root-4 | `su`           | _Not allowed_
+Platform-Users-root-5 | `ssh`          | _Not allowed_
+Platform-Users-root-6 | `scp`          | _Not allowed_
+Platform-Users-root-7 | `sftp`         | _Not allowed_
+
+<!-- end-section-config -->
+
+Root access should not be allowed for the console device. The development
+environment should allow users to login with pre-created user accounts.
+
+Switching to elevated privileges shall be allowed in the development environment
+via `sudo`.
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Capabilities
+
+<!-- section-todo -->
+
+Domain                        | Improvement
+----------------------------- | ------------------------
+Platform-Users-Capabilities-1 | Kernel or Platform-user?
+Platform-Users-Capabilities-2 | Add config note.
+
+<!-- end-section-todo -->
+
+The goal is to restrict functionality that will not be useful in **AGL**. They
+are integrated into the **LSM**. Each privileged transaction is associated with
+a capability. These capabilities are divided into three groups:
+
+- e: Effective: This means the capability is “activated”.
+- p: Permitted: This means the capability can be used/is allowed.
+- i: Inherited: The capability is kept by child/subprocesses upon execve() for example.
diff --git a/docs/security-blueprint/part-5/App-flow.png b/docs/security-blueprint/part-5/App-flow.png
new file mode 100644
index 0000000..7b87c29
--- /dev/null
+++ b/docs/security-blueprint/part-5/App-flow.png