diff options
Diffstat (limited to 'docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md')
| -rw-r--r-- | docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md | 329 |
1 files changed, 181 insertions, 148 deletions
diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md index d491801..3ce894d 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md +++ b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md @@ -1,24 +1,24 @@ --- -edit_link: '' title: Application Framework -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-5/5-AppFw.md --- -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml --> - # 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`. +- **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 applications and services management: Installing, Uninstalling, Listing, + ... - The life cycle of applications: Start -> (Pause, Resume) -> Stop. - Events and signals propagation. - Privileges granting and checking. @@ -31,10 +31,10 @@ The application framework manages: 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. +- 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 --> @@ -50,21 +50,24 @@ 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. +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. +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. +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.  @@ -81,14 +84,16 @@ 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. +- 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. +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: +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. @@ -96,9 +101,9 @@ There are several ways that an attacker can manipulate policies of the Cynara sy - 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. +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 --> @@ -127,36 +132,39 @@ Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. 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). +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. +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/). +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. +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). +securing the interface layer with cryptographic protocols: e.g. encrypted +information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman). ### User-level Native Attacks @@ -167,49 +175,55 @@ e.g. encrypted information passing, key exchange (e.g. Elliptic-Curve Diffie-Hel - 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. +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. +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 @@ -219,58 +233,70 @@ valuable telemetry/analytics capability and the ability to react and renew a sys - 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). +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: +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. +- 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 +- 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. +Normally, the service file is located at +/usr/lib/systemd/user/afm-user-daemon.service. Attacker goals: @@ -286,13 +312,16 @@ Attacker goals: ### Resource: `afm-system-daemon` -The `afm-system-daemon` is in charge of installing applications on the AGL system. Its main tasks are: +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. +- 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. +`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: @@ -302,23 +331,27 @@ Attacker goals: ### 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. +`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: +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. +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 +- Tamper **capabilities** by creating/installing custom bindings for + `afb-daemon`.
\ No newline at end of file |