summaryrefslogtreecommitdiffstats
path: root/docs/security-blueprint/part-5/5-AppFw.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/security-blueprint/part-5/5-AppFw.md')
-rw-r--r--docs/security-blueprint/part-5/5-AppFw.md315
1 files changed, 315 insertions, 0 deletions
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