From 8be9db6f309e1e1b547e187c5db6ceac15f85a50 Mon Sep 17 00:00:00 2001 From: Vinod Ahuja Date: Mon, 7 Nov 2022 16:18:44 -0600 Subject: Fixing the index numbering Fixing the index numbering for all documentation Bug-AGL: [SPEC-4470] Signed-off-by: Vinod Ahuja Change-Id: I96b482a3ab598f0739c692e301de66c0553ba0e4 Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/28118 Reviewed-by: Walt Miner Reviewed-by: Jan-Simon Moeller Tested-by: Jan-Simon Moeller --- .../2_Security_Blueprint/5_Platform.md | 921 --------------------- 1 file changed, 921 deletions(-) delete mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md (limited to 'docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md') diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md b/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md deleted file mode 100644 index 2112fdc..0000000 --- a/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md +++ /dev/null @@ -1,921 +0,0 @@ ---- -title: Platform ---- - -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). - - - -Domain | Improvement -------------------- | -------------------------------- -Platform-Abstract-1 | Create a graphics and sound part. - - - -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). - - - -The tools and concepts used to meet these needs are only examples. Any other -tool that meets the need can be used. - - - -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. - --------------------------------------------------------------------------------- - - - -## 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 - -# Mandatory Access Control - - - -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). - - - -**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. - --------------------------------------------------------------------------------- - - - -## 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 - - - -- 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. - - - -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. - - - --------------------------------------------------------------------------------- - - - -## 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 - - - -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. - - - --------------------------------------------------------------------------------- - - - -## 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 - - - -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. - - - -## 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). - -# 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). - - - -Domain | Object | Recommendations ------------------- | -------------- | ------------------------------------ -Platform-SystemD-1 | Security model | Use Namespaces for containerization. -Platform-SystemD-2 | Security model | Use CGroups to organise processes. - - - -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. - - - -## 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. - -# 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. - - - - -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) - - - -# System services and daemons - - - -Domain | Improvement -------------------- | ----------- -Platform-Services-1 | SystemD ? -Platform-Services-2 | Secure daemon ? - - - -## 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. - - - -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. - - - -# 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. - - - -- 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. - - - -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. - - - -Domain | Object | Recommendations ----------------------- | -------------- | -------------------------------- -Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. - - - -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. - - - -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](images/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. - - - -Domain | Object | Recommendations ------------------------ | ----------- | ------------------------------------- -Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. - - - -### 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 unforeseen 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`. - -# 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. - - - -Domain | `Tool` name | _State_ --------------------- | ----------- | ---------------------------------------------------------------------- -Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. - - - -## 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. - - - -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_ - - - -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. - - - -# 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. - - - -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. - - - -Root access should not be allowed for the following utilities: - - - -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_ - - - -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`. - --------------------------------------------------------------------------------- - - - -## Capabilities - - - -Domain | Improvement ------------------------------ | ------------------------ -Platform-Users-Capabilities-1 | Kernel or Platform-user? -Platform-Users-Capabilities-2 | Add config note. - - - -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. -- cgit 1.2.3-korg