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 | 324 |
1 files changed, 324 insertions, 0 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 new file mode 100644 index 0000000..d491801 --- /dev/null +++ b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md @@ -0,0 +1,324 @@ +--- +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`. + +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. + + + +## 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 |