diff options
| author |   Sebastien Douheret <sebastien.douheret@iot.bzh> | 2018-07-10 12:22:23 +0200 |
|---|---|---|
| committer |   ronan [iot.bzh] <ronan.lemartret@iot.bzh> | 2018-07-12 13:33:16 +0200 |
| commit | 65e5842f843aa67395fce171c8ce602c085d0c11 (patch) | |
| tree | 9e58ab8293478064bc9df116aa55411f6e06dcca | |
| parent | e0df0544ae03e4b5021a4264c608d481659a4be2 (diff) | |
Removed old Security Blueprint chapter: SPEC-1502
As announced on the AGL mailing list and knowing that all sections
and info of old Security Blueprint have been included into 'new'
Security Blueprint, the 'old' Sec Blueprintpart can be removed from
documentation.
Signed-off-by: Sebastien Douheret <sebastien.douheret@iot.bzh>
| -rw-r--r-- | sec-blueprint/01-overview.md | 58 | ||||
| -rw-r--r-- | sec-blueprint/02-adversaries.md | 62 | ||||
| -rw-r--r-- | sec-blueprint/03-threat-analysis.md | 347 | ||||
| -rw-r--r-- | sec-blueprint/04-security-concepts.md | 88 | ||||
| -rw-r--r-- | sec-blueprint/05-platform-security.md | 162 | ||||
| -rw-r--r-- | sec-blueprint/06-application-security.md | 67 | ||||
| -rw-r--r-- | sec-blueprint/07-system-hardening.md | 1250 | ||||
| -rw-r--r-- | sec-blueprint/App-flow.png | bin | 73545 -> 0 bytes | |||
| -rw-r--r-- | sec-blueprint/App_signing_flow.png | bin | 154923 -> 0 bytes | |||
| -rw-r--r-- | sec-blueprint/index.md | 23 |
10 files changed, 0 insertions, 2057 deletions
diff --git a/sec-blueprint/01-overview.md b/sec-blueprint/01-overview.md deleted file mode 100644 index 7a71cee..0000000 --- a/sec-blueprint/01-overview.md +++ /dev/null @@ -1,58 +0,0 @@ ---- - -title : Security BluePrint Overview -date : 2017-07-07 -category: security -tags: security, architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -# Introduction - -## Security in Modern Connected Vehicles - -Modern cars have become a lot more technologically sophisticated and -different than those of the past. We are seeing a wider range of new -features and functionality, with a lot more complex software. It is fair -to say that the cars being introduced to the market today have much -more in common with computing devices like cell phones, than their -predecessors did. Modern car manufacturers are also integrating support -for a broad range of communication technologies for these “connected” -cars. With the advent of such vehicles, Linux has become a natural -choice for the software platform, with Automotive Grade Linux as a -promising example. - -## Connected Car: A Hostile Environment - -From a security point of view, the remote capabilities of a connected -car results in a much larger attack surface. This opens a whole new -world of security vulnerabilities that need to be considered during the -architectural design. History shows that physical access to a device is -sufficient for a hacker to gain root privileges. This makes the car a -`hostile` environment. - -## Abstract - -The Security Blueprint documents the security features that -are included as part of Automotive Grade Linux (AGL) and identifies -areas that need to be addressed from a security perspective as -part of AGL. It also gives guidance around existing technologies and -solutions. Finally it provides recommendations and requirements for -areas that are out of scope of this document and AGL. - - -# Scope -This document will focus on the following key areas: - -* Adversaries - Common categories of Attackers -* Threat Analysis - Common threats to AGL system -* Security Concepts - Technologies and practices that can be used to mitigate attacks -* Platform Security - How AGL applies these security concepts for platform security -* Application Security - How AGL applies these security concepts for application security -* System Hardening - Recommendations on hardening AGL systems diff --git a/sec-blueprint/02-adversaries.md b/sec-blueprint/02-adversaries.md deleted file mode 100644 index 3ece5bb..0000000 --- a/sec-blueprint/02-adversaries.md +++ /dev/null @@ -1,62 +0,0 @@ ---- - -title : Adversaries -date : 2017-07-07 -category: security -tags: security, architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -This section lists some of the adversaries and attackers within the -Automotive space - -# Enthusiast Attackers - Enthusiast attackers have physical access to the Engine Control - Units (ECUs) at the circuit board level. They can solder ‘mod chips’ - onto the board and have access to probing tools. They also have - information on ECUs that have been previously compromised and have - access to softwares and instructions developed by other members - of car modification forums. The goal of the enthusiast hacker - could be, but is not limited to, adding extra horse power to the - car or hacking it just for fun. - -# Corrupt Automotive Dealers - Corrupt automitive dealers are attackers that have access to the - same capabilities as enthusiasts, but also have access to the car - manufacturer's (OEM) dealer network. They may also have access to - standard debugging tools provided by the car manufacturer. Their - goal may be to support local car theft gangs or organized criminals. - -# Organized Criminals - Organized criminals have access to all of the above tools but may - also have some level of control over the internal network at - many dealerships. They may have hacked and gained temporary - control of the Over-The-Air (OTA) servers or the In-Vehicle - Infotainment (IVI) systems. This is very much like the role of - organized criminals in other industries such as paid media today. - Their goal is to extort money from OEMs and/or governments by - threatening to disable multiple vehicles. - -# Malware Developers - Malware developers have developed malicious software to attack - and compromise a large number of vehicles. The malicious software - is usually designed to spread from one vehicle to another. - Usually, the goal is to take control of multiple machines and then sell - access to them for malicious purposes like denial-of-service (DoS) - attacks or theft of private information and data. - -# Security Researchers - Security researchers are ‘self-publicized’ security consultants trying - to make a name for themselves. They have access to standard tools for - software security analysis. They also have physical access to the - vehicle and standard hardware debugging tools (Logic Analyzers, - Oscilloscopes, etc). Their goal is to publicize attacks for personal - gain or just to gain personal understanding with a sense of helping make - things more secure. - diff --git a/sec-blueprint/03-threat-analysis.md b/sec-blueprint/03-threat-analysis.md deleted file mode 100644 index deab845..0000000 --- a/sec-blueprint/03-threat-analysis.md +++ /dev/null @@ -1,347 +0,0 @@ ---- - -title : Threat Analysis & Coverage -date : 2017-07-07 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -# Introduction - -The Automotive Grade Linux (AGL) platform has set out to be an open source solution for automotive applications. With an open system come many avenues of attack by the spectrum of attackers, from hobbyists to university students to well-funded hacking organizations. AGL introduces an application framework and has adopted the Cynara system from Tizen, which uses SMACK as its kernel-level underpinnings. - -This document first looks at attack goals and how the intruder may get to these goals. Then attacks on specific assets of the system are considered. Further, the analysis looks at the attack surface and possible branches into these assets. As these avenues are analyzed, we discuss mitigations individually and broader approaches, such as defense-in-depth which resists an attacker's ability to attain their goals by deploying *overlapping* defenses. - -This threat analysis was written from an investigation of the following sources of information: - -* AGL on-line documentation. -* The AGL source code-base, Charming Chinook Release, made available on Jan 6, 2017. -* Tizen documentation, on-which the security features of AGL have been based. - -## Attack Goals - -In today's connected vehicle, more and more functionality is moving to software control, meaning that the threat of attack becomes greater and greater. We see car features like navigation and summoning, car access/engine start, and motor/ECU upgrades all controlled through software and connections to the cloud. The risk of attack is high because there are high value targets in play. - -Here, we outline some of the major threats categories along with some sample attackers, example attacks, and a relative importance. These threat categories are intended to be general examples. There can be many nuances to threat types. Additionally, there can be many *sub*-attacks that eventually lead to these higher level attack goals. - -| Threat Category | Sample Attacker | Example Attacks | Relative Importance | -| --------------- | --------------- | -------- | ---------- | -| Vehicle theft | Individual, organized criminals | Send the car to an unplanned destination, get a key for the car, gain control of the unlock mechanism | Reduced likelihood of future vehicle purchases (Profit Later), bad press (Brand Integrity) | -| Reduced vehicle functionality | Terrorist groups, disgruntled employees | Lock the driver out of the car, cause the car to crash, block access to infotainment system | Inability sell paid-for apps and content (Profit Now), bad press (Brand Integrity), possible loss of life (Physical Injury) | -| Vehicle hacking | Vehicle owner, competitor | Get content without paying, modify DRM licenses, unlock of after-market features, theft of IP | Loss of sales for content and features (Profit Now), lawsuits from content owners (Profit Later), loss of competitive advantage (Profit Later) | -| Sensitive asset theft | Organized criminals, blackmailers | Steal credit card numbers, health information, camera data, steal bandwidth | Bad press (Brand Integrity), lawsuits from vehicle owners (Profit Later) | - -## Assets and Security Categorization - -This section outlines some of the assets that are likely to be found in the vehicle and their relative sensitivity from an attack point of view. Additionally, the final column on the right lists some of the recommended protection types that can be applied to these types of assets (Note that the empty cells refer to the cells above them). A good protection approach will give priority to the most sensitive assets, using a defense-in-depth approach to cover these assets. Less sensitive assets are treated at a lower priority, typically protected with fewer protection techniques. A more fine-grained prioritziation of the the assets in a concrete vehicle network can be achived with detailed threat analysis which considers the topology of the vehicle network and access-controls that are in-place. e.g. the EVITA framework for attack trees. - -| Asset Category | Examples | Sensitivity | Recommended Protection Types | -| -------------- | -------- | ----------- | ---------------------------- | -| Software | ECU software, infotainment software, OS images | Critical | Key Management, Mutual Asymmetric Authentication, HSM and WhiteBox Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms/ Obfuscation, Integrity Verification, Secure OS | -| Car Access | Biometric data, car keys | | | -| Payment Data | Credit cards, User profile critical data | | | -| Recordings | Internal camera recording, internal audio recording, external camera recording | High | Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms / Obfuscation | -| User Profile | Usernames and passwords, customization, calendar, contacts | | | -| Location | GPS coordinates, vehicle usage data | | | -| Purchased Content | Video, audio, licenses | | | -| Teleconference | Chat, audio, video | Medium | SW Protection, Program Transforms / Obfuscation, Authenticated encryption for transmission -| Vehicle data | Vehicle info, sensor data | | | -| Navigation data | Static and dynamic maps | | | -| 3rd party data | Home automation commands, cloud game data | | | - -# Execution Environment - -The execution environment used for AGL leverages a Linux kernel combined with an application framework. The foundation of the environment is a pre-configured Linux kernel which will inherit any existing vulnerabilities associated with the kernel. The following are, therefore, important to the system: - -## Kernel Version - -The choice of kernel version for the AGL system is essential to its security. Depending on the type of board and eventual production system, different kernel versions are used. For example, one of the systems under study uses the Linux kernel version 3.10, while another uses the Linux kernel version 4.4. For the Linux kernel version 3.10.31, there are [25 known vulnerabilities](https://www.cvedetails.com/version/194332/Linux-Linux-Kernel-3.10.31.html). These vulnerabilities would allow an attacker to gain privileges, bypass access restrictions, allow memory to be corrupted, or cause denial of service. In contrast, the Linux kernel version of 4.4 has [many fewer known vulnerabilities](https://www.cvedetails.com/version/190796/Linux-Linux-Kernel-4.4.html). For this reason, we would in general recommend the later kernel version as a basis for the platform. - -Note that, although there are fewer *known* vulnerabilities in the most recent kernel versions there may be many unknown vulnerabilities underlying. A rule of thumb is to update the kernel as much as possible to avoid the problems you do know, but you should not be complacent in the trust that you place in it. A defense-in-depth approach would then apply. - -If there are constraints and dependencies in upgrading to a newer kernel version (e.g. device drivers, board support providers) and you are forced to an older Linux kernel version, there need to be additional provisions made to reduce the risk of kernel exploits, which can include memory monitoring, watch-dog services, and system call hooking. In this case, further defense-in-depth techniques may be required to mitigate the risk of attacks to known vulnerabilities, which can also include runtime integrity verfication of components that are vulnerable to tampering. - -## Kernel Build Configuration - -The kernel build configuration is extremely important for determining the level of access to services and to reduce the breadth of the attack surface. Linux contains a great and flexible number of capabilities and this is only controlled through the build configuration. For example, the *CONFIG_MODULES* parameter allows kernel modules to be loaded at runtime extending the capabilities of the kernel. This capability needs to be either inhibited or controlled at runtime through other configuration parameters. For example, *CONFIG_MODULE_SIG_FORCE=y* ensures that only signed modules are loaded. There is a very large number of kernel configuration parameters, and these are discussed in detail in [the hardening guide of the AGL security blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/08-Hardening.html) - -## Discretionary Access Control - -Discretionary Access Control (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 Mandatory Access Control (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 - -Mandatory Access Control (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. - -## Application Types - -AGL provides a framework for applications to be written in different forms: - -* Web application: HTML5 + JavaScript -* Qt application: in a QML file -* Native application: in C - -While there is no harm in providing multiple types of applications, from a security perspective this does increase the attack surface for an intruder. The application framework consists of a number of utilities and daemons which provide context for the applications. Isolation is provided through SMACK labels. - - -# Application Security Model - -The AGL application framework consists of several interworking parts: - -* SMACK - Simplified Mandatory Access Control Kernel, the kernel level LSM (Linux Security Module) 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 - -## Application Framework - -The [AGL app framework](http://iot.bzh/download/public/2016/appfw/02_Documentation-AppFW-Core-2.0.pdf), provides the management around installation, starting/stopping, bindings to D-Bus, and communications to Cynara and the Security Manager. Installation of applications flows through the `afm_system_daemon` and the `security_manager`. The Security Manager retains information in an SQLite database and also sets SMACK policies. The Security Manager also has the definition of an API for external entities. - -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. - - - -### 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; and 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 - -## Cynara - -[Cynara](https://wiki.tizen.org/Security:Cynara) was adopted from the Tizen security framework and 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](https://wiki.tizen.org/Security:Cynara:Storage). - -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. - -## SMACK - -Linux Security Modules (LSM) is a framework in the linux kernel which provides the ability to implement Mandatory Access Control (MAC) with different models. The SMACK model is a simplified mandatory access control, starting with character-based labels on files and directories. There are 4 major components to the system: - -1. The LSM kernel module. -2. The `smackfs` filesystem. -3. Basic utilites for policy management and checking -4. 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. -* Tamperig 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). - -# Application Store - -Although the Tizen system has defined a [system of App signing and signing flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates) to avoid the spread of unauthorized Apps that might contain malware. At this point, it is unclear how much of this flow AGL will adopt; however, judging from the experience, it is an essential topic. For example, the Google Play Store controls the authorization of Apps through signing, and still, there are [many accounts of Apps containing malware on the store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play). - -Tizen defines 5 levels of certificates and signing at each level, including an author, testing distributor, public level store distributor, partner level store distributor, and platform level store distributor. AGL may define a different number of third parties, but at a minimum an author and store distributor should be defined. - - - -Once the number of signatures has been established, verification of those signatures needs to be done at a minimum at installation time on the AGL device. It is important to ensure the robustness/integrity of the public key used for signature verification. If the public key is modified, then this compromised key can be used to verify an attacker's private key signature. - -Further to this, installation-time verification is limited. Attacks can happen to apps in-memory at runtime. Any modifications made after installation will be missed by installation-time verification. Integrity verification that runs during execution makes for a more complete security story. - -# External Threats - -## Attacks from the Cloud - -### OTA Updates - -Updates of software over-the-air are one of the most common points where an attacker will penetrate. An OTA update mechanism is one of the highest threats in the system. If an attacker is able to install his own application or firmware on the system, he can get the same level of access that the original application or firmware had. From that point, the intruder can get unfettered access to the rest of the system, which might include making modifications, downloading other pieces of software, and stealing assets. - -#### Man-in-the-middle (MITM) - -The man-in-the-middle attack is the most classic example of an attack, where an adversary inserts himself between two communicating entities and grabs whatever is being communicated. In the case of OTA attacks, the connection in the network may be intercepted: - -* On the internet, before the cloud backend. -* At the base station, 3G,4G,5G connection to the internet. -* At the receiving antenna, connection to the car. -* Between the receiving antenna and the gateway router (if present), connection within the car. -* Between the gateway router and the target component (IVI, In-Vehicle Infotainment unit). - -There are many ways to mount a MITM attack. For example, proxy tools like Burp Proxy can be used to intercept web traffic as a man-in-the-middle. Under the guise of being a testing tool, the proxy server is often used in attack scenarios. It runs on a variety of platforms. - -As another example, false base station attacks are known to be fairly easy to set-up. The problem is apparently fairly prevalent in countries like China and in the UK. These fake base stations are sometimes just eavesdropping on the communication, but others have the potential to do serious harm. - -Defenses against MITM attacks include encrypted and signed data pipes. Furthermore, architects and developers are also recommended to encrypt and sign the payloads that are being passed over these pipes, to defend against perusal of the data. - -### Man-at-the-end (MATE) Attacks - -The man-at-the-end attack is when an intruder analyzes the end-point of the communication when software is accessing the data communication. This is a more severe attack type where the attacker can: - -* Steal keys. - - For example, a simple debugging session in running software could reveal a key used in memory. - -* Tamper software. - - For example, replacing just one function call in software with a NOP (i.e. no operation) can drastically change the behavior of the program. - -* Jam branches of control. - - For example, making a program take one branch of control rather than the intended branch can mean the difference between an authorized and a non-authorized installation. - -* Modify important data. - - For example, if the data changed is a key or data leading to a control path, then this attack can be severe. - - In the case of OTA updates, MATE attacks are particularly problematic for the system. One of the consequences of MATE attacks can be installed software that allows installation of any other software. For example, an attacker might install remote access software to control any part of the system. - - - -## Malicious Physical Attacks - -### CAN & USB devices - -On just about every vehicle, ECUs (Electronic Control Units) communicate over a CAN (Controller Area Network) bus, which is a two-wire bus using hardware arbitration for messages sent on the shared medium. This is essentially a *trusted* network where all traffic is visible to all controllers and any controller can send any message. - -A malicious ECU on the CAN bus can easily inject messages destined for any other device, including things like the instrument cluster and the head unit. There are common ways for hardware to do USB to CAN and open source software to send and receive messages. For example, there is a driver included in the Linux kernel that can be used to send/receive CAN signals. A malicious device on the CAN bus can cause a great number of harmful things to happen to the system, including: sending bogus information to other devices, sending unintended commands to ECUs, causing DOS (Denial Of Service) on the CAN bus, etc. - - -# Conclusion - -The Automotive Grade Linux (AGL) initiative builds upon open-source software including Linux and Tizen to offer a flexible application framework. However, the security provisions of the app framework, Cynara, and the security manager only go so far in keeping the biggest threats at bay. As experience has shown, providing a constrained app (like that in the Android Open Source Platform) and store development flow, signature verification, DAC sandboxing, and MAC (SMACK) controls over the platform can have a certain amount of success with the security of the system. However, the openness of the system invites many researchers, hobbyists and hackers and financially motivated attackers to compromise the system for their own gains. - -As AGL arrives on modern automobiles, this is inevitably inviting many capable actors to modify, attack, and compromise these well thought-out systems and their applications. With concerns like safety and security, the auto industry cannot afford to go the way of consumer devices like phones and tablets where security problems are encountered on a frequent basis. It is imperative to use a layered approach and defense-in-depth to protect the system from inevitable attack. - -This document has described both general attack goals and specific threats to the AGL system. While those may think that a remote attack is the biggest concern, the reader should be aware that an open-source software system invites people to first research direct attacks before crafting remote attacks. Don't underestimate the creative ability for hackers to find the weakest link in a product. This has been shown time and time again in open products. - diff --git a/sec-blueprint/04-security-concepts.md b/sec-blueprint/04-security-concepts.md deleted file mode 100644 index 5080b4c..0000000 --- a/sec-blueprint/04-security-concepts.md +++ /dev/null @@ -1,88 +0,0 @@ ---- - -title : Security Concepts -date : 2017-07-07 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - - -This document addresses the following security concepts that help make -connected vehicles less vulnerable to security threats. - -## Secure Boot - -Secure boot refers to preventing malicious software applications and -"unauthorized" operating systems from loading during the system start-up -process. The goal is to protect users from rootkits and other -low-level malware attacks. Modern bootloaders come with features that -can be used to enable secure boot in the system. - -## Software Integrity - -The goal of software integrity is to ensure that all software running on -a system has not been altered in any way, either accidentally or -maliciously. This is typically achieved by checking a file's hash or -signature against a protected, “good” value that exists in the system. -Maintaining software integrity ensures that your system behaves as -intended. In principle, it protects the system against any malicious -code trying to tamper your system. - -## Secure Update/Upgrade - -Software updates in connected vehicles are a very useful feature, which -can deliver significant benefits. If not implemented with security in -mind, software updates can incur serious vulnerabilities. Any software -update system must ensure that not only are the software updates to -devices done in a secure way, but also that the repositories and servers -hosting these updates are adequately protected. As the process of updating -software migrates from a `Dealership` update model towards an `Over-The-Air` -update model, securing these processes becomes a high priority. - -## Layered Security - -It has been well established amongst software security researchers, that -a layered approach to security ensures a stronger protection against attackers. -A multi-layered approach to security should be included when designing the -architecture of a connected car. The goal is to ensure that even if one layer -of security is compromised, the other layers will protect the platform, while at the -same time making it harder for attackers to breach the security of the -system. - -## Read-Only File Systems - -When following a layered security design, one simple yet effective way -to protect the platform is to make the file system read-only. It is -important to note that making the filesystem read-only is not a -foolproof security mechanism. It does, however, make life more complex -for an attacker. - -## Mandatory Access Control - -Mandatory Access Control (MAC) refers to a type of access control in a -Linux system that constrains the ability of a “subject” to access a -“resource”. The Linux kernel makes these decisions based on a -pre-existing policy. User are not allowed to override or modify this -policy, either accidentally or intentionally. MAC uses the underlying -kernel framework of Linux Security Modules (LSM). There are multiple -LSMs available including SELinux, Simplified Mandatory Access Control -Kernel (SMACK), AppArmor and others. AGL uses SMACK as the MAC. - -## Secured Applications - -Applications in the modern car are steadily improving the dashboard and -control of the car. Applications have also proven to be frequent point -of attack for hackers. In AGL, The term of Application (App) has a very -wide definition. Almost anything which is not in the core OS is considered -an Application. At the same time, when talking about the security of applications, -any mobile applications that have been designed to interact with the car -must also be considered. Secured applications are mission-critical for OEMs -who want to meet customer expectations for innovative software features, -while ensuring the safety and proper functioning of their vehicles. diff --git a/sec-blueprint/05-platform-security.md b/sec-blueprint/05-platform-security.md deleted file mode 100644 index 9bf96d6..0000000 --- a/sec-blueprint/05-platform-security.md +++ /dev/null @@ -1,162 +0,0 @@ ---- - -title : Platform Security -date : 2017-07-07 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -This section describes how the Automotive Grade Linux (AGL) platform -applies some of the previously described security concepts to -implement platform security - -# Platform Definition -The Automotive Grade Linux(AGL) platform is a Linux distribution -with AGL compliant applications and services. The platform includes the -following hardware: - - SoC (System-on-Chip) - - Memory (RAM, ROM, storage, etc.) - - Peripherals - -The AGL 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 - - Building and debug tools (based on Yocto project) - -For more details, refer to the AGL Architecture/Specification Document. - -# Secure Boot -Currently, AGL does not provide a secure boot solution but highly recommends -that the manufactured solution make use of a secure boot mechanism. For -instructions on securing u-boot, please refer to the System Hardening Guide. - -# Certificate and Key Management -Currently, AGL does not provide a secure certificate and key management -solution but highly recommends that the manufactured solution make use -of secure key management. - -# Mandatory Access Control -Mandatory Access Control (MAC) is a protection provided -by the Linux kernel that requires a Linux Security Module (LSM). -AGL uses an LSM called Simplified Mandatory Access Control Kernel (SMACK). -This protection involves the creation of SMACK labels as part of the extended -attributes SMACK *labels* to the extended attributes of the file and then -creation of a policy to define the behaviour of each label. The kernel controls -access based on these labels and this policy. - -There are two types of SMACK labels. -* An *Execution* SMACK label of a process defines how files -are accessed and created by that process. - -* The *File Access* SMACK label defines which process can access the file. -This SMACK label is written to the extended attribute of 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 -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 by installation and upgrade software. - -The following table details the *floor* domain: - -------------------------------------------------------------------------------------------------------------------------- - -|Label| Name | File | Process | Comment | -|:-:|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -| - | Floor | r-x for all | Only kernel and<br>internal kernel thread <br>| -- | -| ^ | Hat | --- for all | rx on all domains | 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. | -| * | Star | rwx for all | None | used for device files or /tmp Access restriction managed via DAC. Individual files remain protected by their SMACK label. | - - - -## 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 | File | Process | Comment | -|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -|System|System|none|Privileged<br>processes|Process should write only to file with transmute attribute.| -|System::run|Run|rwxatl for User and System label|None|Files are created with the directory label<br>from user and system domain (transmute)<br>Lock is implicit with w.| -|System::shared|Shared|rwxatl for system domain<br>r-x for User label|None|Files are created with the directory label from system domain (transmute)<br>User domain has locked privilege| -|System::Log|Log|rwa for System label<br>xa for user label|None|Some limitation may impose to add w to enable append.| -|System::Sub|SubSystem|Subsystem Config files|SubSystem only|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 in this domain is under Cynara -control. - -The following table details the *application, services and user* domain: - -------------------------------------------------------------------------------------------------------------------------- - -|Label| Name | File | Process | Comment | -|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -|App::$AppID|AppID|rwx (for files created by the App).<br>rx for files installed by AppFW|$App runtime<br>executing $App|Only one Label is allowed per App.<br>A data directory is created by the AppFW in rwx mode.<br>Older releases still use User::App::$AppID | -|User::Home|Home|rwx-t from System label<br>r-x-l from App|None|AppFW needs to create a directory in /home/$USER/App-Shared at first launch if not present with label<br>app-data access is "User::App-Shared"<br>without transmute.| -|App-Shared|Shared|rwxat from System and User domains label of $User|None|Shared space between all App running for a given user.<br>Older releases may still use User::App-Shared| - -# Yocto Security Layer -Currently, AGL relies on Cynara and Security Manager from Yocto Layer -meta-intel-iot-security. Please note that support for these components has -been dropped in the upstream project. - -# Application API Transport -Currently, AGL Application framework uses D-Bus interface for transport -and uses the inherent security that comes with this protocol. - -# Resource Management and Protection -AGL provides resource management and protection through SMACK labels. -Please refer to application framework documentation for more details. - -# TrustZone -Currently, AGL does not provide any direct support for TrustZone. -This feature strictly depends on the SoC and is only available on ARM architectures. - -# AGL Platform Software Update - -The update solution must be atomic and the following update requirements: -- Support Smack as MAC -- Support Read-Only Filesystem -- Support Integrity Enforcement - -Currently AGL offers a reference implementation of the Over-The-Air -update system using OSTree. Work is being done to secure the OTA -updates using *Uptane*. - -For more information on Uptane, please refer to: - -https://uptane.github.io/ - -# Cloud Service Infrastructure -Currently, AGL does not provide a any cloud service infrastructure - - -For recommendations on hardening the system, please refer to the System Hardening Guide. diff --git a/sec-blueprint/06-application-security.md b/sec-blueprint/06-application-security.md deleted file mode 100644 index 44a4622..0000000 --- a/sec-blueprint/06-application-security.md +++ /dev/null @@ -1,67 +0,0 @@ ---- - -title : Application Security -date : 2017-07-07 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -This section describes how the Automotive Grade Linux (AGL) platform -applies some of the previously described security concepts to -implement application security - -# Application Definition -The term of Application (App) has a very wide definition in AGL. -Almost anything which is not in the core Operating System (OS) is an Application. -Applications can be included in the base software package (image) or -can be added at run-time. - -# Application Installation -Applications are installed under the control of the Application Framework (AppFw). -Applications can be delivered and installed with the base image using a -special offline-mode provided by the Application Framework. Apps can also be installed -at runtime. - -**Note** In early release, default Apps are installed on the image at first boot. - -# Application Containment -Application containment is achieved using the following protections: - -* **Linux Native protection** - * Mandatory Access Control (SMACK) -* **AGL Platform protections** - * Origin Tracking and Validation - * Application Privilege Management and Enforcement via Cynara - * Authenticated Transport via D-Bus - -## Mandatory Access Control -Mandatory Access Control (MAC) is a protection provided -by the Linux kernel that requires a Linux Security Module (LSM). -AGL uses an LSM called Simplified Mandatory Access Control Kernel (SMACK). -This protection requires writing SMACK *labels* to the extended attributes of the file -and then writing a policy to define the behavior of each label. -The kernel controls access based on these labels -and this policy. -For more details on SMACK scheme in AGL, please refer to the -security platform security document in the security blueprint. - -## Origin Tracking and Validation -Currently, AGL applications are tracked and verified at installation -time by the application and security framework using SMACK labels. -For more details, please refer to the application framework documentation. - -## Privilege Management and Enforcement -Application priveleges are managed by Cynara and the security manager -in the application framework. -For more details, please refer to the application framework documentation. - -## Autenticated Message Transport -Currently AGL uses the D-Bus interface for transport, using the security -inherent in this interface. diff --git a/sec-blueprint/07-system-hardening.md b/sec-blueprint/07-system-hardening.md deleted file mode 100644 index 5ffe501..0000000 --- a/sec-blueprint/07-system-hardening.md +++ /dev/null @@ -1,1250 +0,0 @@ ---- - -title : System Hardening -date : 2017-05-23 -categories: security, hardening, automotive -tags: security, hardening, architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -# Overview - -## Scope - -This document provides recommended guidelines for adding protection to an -embedded system. The information contained in this document is applicable -to systems based on Automotive Grade Linux. - -## Limitations - -- This document is based on knowledge and research gained from looking - at security desktop and server versions of Linux as well as Android - exploits and hardening. - -- Some kernel configuration options can have an impact on performance. - This will be noted where applicable. - -## Document Structure - -This document has been divided into three sections; REQUIREMENTS, -RECOMMENDATIONS, and VALIDATION. The REQUIREMENTS section details -explicit requirements that must be adhered to for the embedded -device. -The RECOMMENDATIONS section details best practices, and some -recommended security settings for the embedded device. -The third section, VALIDATION, provides reference scripts and test procedures that -can be used to verify adherence with the REQUIREMENTS detailed in the -first section of this guide. - -## Hardening - -The term *Hardening* refers to the tools, techniques and processes -required in order to reduce the attack surface on an embedded system, -such as an embedded control unit (ECU) or other managed device. -The target for all hardening activities is to prevent the execution of -invalid binaries on the device, and to prevent copying of security -related data from the device. -There are three main areas of focus for hardening an embedded device: - -**Boot Hardening**: Steps/requirements to configure the boot sequence, -in order to restrict the device from executing anything other than the -approved software image. - -**System Hardening**: Best practices associated with the configuration -of an embedded Linux based operating system. This section includes both -hardening of the kernel itself, as well as specific configurations and -patches used to protect against known vulnerabilities within the build -and configuration of the root filesystem. - -**Application Hardening:** Best practices to apply to the build and -release of user space applications, in order to reduce the number of -attack surfaces used by potential attackers. - -## Secure Boot Software Flow Steps - -1. After power on, the processor will perform the verification - of the Stage 1 boot image, the stage 2 boot image and the Secure - loader image. - - a. If any of the images fail the verification process the device - will not boot. - -2. Upon successful verification of all of the boot and loader images, - the secure process will initiate the Stage 1 boot process. - -3. The Stage 1 boot process will perform processor initialization, and - then initiate the Stage 2 boot process. - -4. The Stage 2 boot process will initiate the Secure Loader, which will - process any customer specific customizations (e.g. front panel - of ECU, USB based image updates, etc). - -5. The Secure Loader will check to determine if there are any updates - to be processed. If the update settings indicate that an upgrade - should occur then the Secure Loader will will determine the correct - action based on the nature of the upgrades: - - a. If the Secure Loader determines that an upgrade was performed - (or attempted), it will initiate the reboot process. - - b. If no upgrades were processed: then the Secure Loader will pass - control back to the Stage 2 boot process for further processing - -6. The Stage 2 boot process will continue with the boot process, by - performing a verification of the kernel image prior to the load of - that image - - a. If the kernel image verification fails, the Stage 2 boot loader - will not boot - -8. The Stage 2 boot loader will load the successfully verified kernel - and boot the linux OS - -9. The booted Linux OS will perform the normal Linux init sequence - -10. The Linux init process will start the required applications and - services as described in the init process and present on the rootfs. - -# Requirements - - For the purposes of reference and explanation, we are providing guidance - on how to configure an embedded device that runs with a 3.10.17 - Linux kernel, and includes the use of U-Boot as the *Stage 2* - These requirements must still be met by manufacturers that - opt to build using an alternative version of the Linux kernel. - -## Hardened Boot - -### Boot image selection - -The boot process shall be uninterruptable and shall irrevocably boot the -image as specified in the boot environment. - -In U-Boot set the “**bootdelay**” environment variable and/or define -CONFIG\_BOOTDELAY to -2. - -### Verifying Authenticity of booting image - -It shall not be possible to boot from an unverified image. - -The secure boot feature in U-Boot shall be enabled. The secure boot -feature is available from U-Boot 2013.07 version. - -To enable the secure boot feature, enable the following features: - -``` -CONFIG_FIT: enables support for Flat Image Tree (FIT) uImage format. -CONFIG_FIT_SIGNATURE: enables signature verification of FIT images. -CONFIG_RSA: enables RSA algorithm used for FIT image verifitcation. -CONFIG_OF_CONTROL: enables Flattened Device Tree (FDT) configuration. -CONFIG_OF_SEPARATE: enables separate build of u-Boot from the device tree. -CONFIG_DEFAULT_DEVICE_TREE: specifies the default Device Tree used for the -run-time configuration of U-Boot. -``` - -Generate the U-Boot image with public keys to validate and load the -image. It shall use RSA2048 and SHA256 for authentication. - -### Disable USB support - -To disable USB support in U-Boot, following configs shall not be -defined: - -``` -CONFIG_CMD_USB: enables basic USB support and the usb command -CONFIG_USB_UHCI: defines the lowlevel part. -CONFIG_USB_KEYBOARD: enables the USB Keyboard -CONFIG_USB_STORAGE: enables the USB storage devices -CONFIG_USB_HOST_ETHER: enables USB ethernet adapter support -``` - -### Console / Remote Access - -Serial console output shall be disabled. To disable console output in -U-Boot, set the following macros: - -``` -CONFIG_SILENT_CONSOLE -CONFIG_SYS_DEVICE_NULLDEV -CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC -``` - -and set “***silent”*** environment variable. - -For the Secure loader, disable the traces by undefining the below macro - -``` -INC_DEBUG_PRINT -``` - -For sboot proper configuration needs to be done to disable the serial -console. - -### Field upgrades - -Field upgrades can be achieved securely by using a Secure Loader. -This loader will authenticate an incoming image (USB,Serial, Network) -prior to writing it to the flash memory on the device. It should not be -possible to write to flash from bootloader (U-Boot). Note that because - USB support is to be disabled within the sboot/U-Boot code, the board -specific implementation of the Secure Loader will have to manage the -entire USB initialization, enumeration, and read/write access to the -mass storage device. - -### Disable USB, Serial, Docsis support - -Disable USB support in sboot. In addition, disable unnecessary communication -modes like Ethernet, Serial ports, DOCSIS in U-Boot and sboot that are -not necessary. - -### Immutable Environment variables - -In U-Boot, ensure Kernel command line, boot commands, boot delay and -other environment variables are immutable. This will prevent -side-loading of alternate images, by restricting the boot selection to -only the image in FLASH. - -The environment variables shall be part of text region in U-Boot as -default environment variable and not in non-volatile memory. - -Remove configuration options related to non-volatile memory such as: - -``` -#define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_IS_IN_EEPROM -#define CONFIG_ENV_IS_IN_FLASH -#define CONFIG_ENV_IS_IN_DATAFLASH -#define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_IS_IN_FAT -#define CONFIG_ENV_IS_IN_NAND -#define CONFIG_ENV_IS_IN_NVRAM -#define CONFIG_ENV_IS_IN_ONENAND -#define CONFIG_ENV_IS_IN_SPI_FLASH -#define CONFIG_ENV_IS_IN_REMOTE -#define CONFIG_ENV_IS_IN_UBI -``` - -and include the following definition: - -``` -#define** CONFIG_ENV_IS_NOWHERE -``` - -## Kernel Hardening - - The following sub-sections contain information on various kernel - configuration options to enhance the security measures in the kernel - and also for applications compiled to take advantage of these security - features. - Additionally, there are also configuration options that - close known vulnerable configuration options. - Here’s a high level summary of various kernel configurations that - shall be required for deployment. - -### Disable the serial console - - The serial console should be disabled to prevent an attacker from - accessing this powerful interface. - -```bash - CONFIG_SERIAL_8250=n - CONFIG_SERIAL_8250_CONSOLE=n - CONFIG_SERIAL_CORE=n - CONFIG_SERIAL_CORE_CONSOLE=n -``` - -### Restrict access to kernel memory through device file - - The /dev/kmem file in Linux systems is directly mapped to kernel - virtual memory. - This can be disastrous if an attacker gains root - access, as the attacker would have direct access to kernel virtual - memory. - - To disable the /dev/kmem file, which is very infrequently used by - applications, the following kernel option should be set in the - compile-time kernel configuration: - -``` - CONFIG_DEVKMEM=n -``` - - In case applications in userspace need /dev/kmem support, it should be - available only for authenticated applications. - -### Bake-in the kernel command-line - - The kernel command-line is used to control many aspects of the booting - kernel, and is prone to tampering as they are passed in RAM with - little to no reverse validation on these parameters. - To prevent this type of attack, the kernel shall be configured to ignore command line - arguments, and use pre-configured (compile time) options instead. - - Set the kernel command line in the CONFIG\_CMDLINE KConfig item and - then pass no arguments from the bootloader. - -```bash - CONFIG_CMDLINE_BOOL=y - CONFIG_CMDLINE=”insert kernel command line here” - CONFIG_CMDLINE_OVERRIDE=y -``` - - It is recommended that any per-device settings (eg. MAC addresses, - serial numbers, etc.) be stored and accessed from read-only memory (or - files), and that any such parameters be verified (signature checking) - prior to their use. - -### Disable kernel debug symbols - - Debug symbols should always be removed from production kernels as they - provide a lot of information to attackers. - -```bash - CONFIG_DEBUG_INFO=n -``` - - These kernel debug symbols are enabled by other config items in the - kernel. - Care should be taken to disable those also. - If CONFIG\_DEBUG\_INFO cannot be disabled then enabling - CONFIG\_DEBUG\_INFO\_REDUCED is second best. - -### Disable access to a kernel core dump - - This kernel configuration disables access to a kernel core dump from - user space -- if enabled it gives attackers a useful view into kernel - memory. - -```bash - CONFIG_PROC_KCORE=n -``` - -### Disable KGDB - - The Linux kernel supports KGDB over USB and console ports. These - mechanisms are controlled by the kgdbdbgp and kgdboc kernel - command-line parameters. - It is important to ensure that no shipping - product contains a kernel with KGDB compiled-in. - -```bash - CONFIG_KGDB=n -``` - -### Disable Kprobes - - Kprobes enables you to dynamically break into any kernel routine and - collect debugging and performance information non-disruptively. - You can trap at almost any kernel code address, specifying a handler - routine to be invoked when the breakpoint is hit. - -```bash - CONFIG_KPROBES=n -``` - -### Disable Tracing - - FTrace enables the kernel to trace every kernel function. - Providing kernel trace functionality would assist an attacker in discovering attack vectors. - -```bash - CONFIG_FTRACE=n -``` - -### Disable Profiling - - Profiling and OProfile enables profiling the whole system, include the kernel, - kernel modules, libraries, and applications. - Providing profiling functionality - would assist an attacker in discovering attack vectors. - -```bash - CONFIG_OPROFILE=n - CONFIG_PROFILING=n -``` - -### Disable magic sysrq support - - On a few architectures, you can access a powerful debugger interface - from the keyboard. - The same powerful interface can be present on the serial console - – responding to serial break – of Linux on other architectures. - Disable to avoid potentially exposing this powerful backdoor. - -```bash - CONFIG_MAGIC_SYSRQ=n -``` - -### Disable OOPS print on BUG() - - The output from OOPS print can be helpful in Return Oriented - Programming (ROP) when trying to determine the effectiveness of an - exploit. - -```bash - CONFIG_DEBUG_BUGVERBOSE=n -``` - -### Disable kexec - - This prevents someone who gets root from supplanting the kernel. - This can be used as a way to bypass signed kernels. - -```bash - CONFIG_KEXEC=n -``` - -### Disable kernel IP autoconfiguration - - It is preferable to have IP configuration performed using a user-space - tool as these tend to have more validation. - We do not want the network - interface coming up until the system has come up properly. - -```bash - CONFIG_IP_PNP=n -``` - -### Disable /proc/config.gz - - It is extremely important to not expose the kernel configuration used - on a production device to a potential attacker. - With access to the - kernel config, it could be possible for an attacker to build a custom - kernel for the device that may disable critical security features. - -```bash - CONFIG_IKCONFIG=n -``` - -### Disable swap - - If not disabled, attackers can enable swap at runtime, add pressure to - the memory subsystem and then scour the pages written to swap for - useful information. - -```bash - CONFIG_SWAP=n -``` - -### Disable NFS file system - - While often enabled in development, when left enabled in production - builds this can be a very useful way for an attacker to get files onto - and off of an STB. - -```bash - CONFIG_NFSD=n - CONFIG_NFS_FS=n -``` - -### Disable support for binary formats other than ELF - - This will make possible to plug wrapper-driven binary formats into - the kernel. - It enables support for binary formats other than ELF. - Providing the ability to use alternate interpreters would assist an attacker in - discovering attack vectors - -```bash - CONFIG_BINFMT_MISC=n -``` - -### Disable “Load All Symbols” - - There is a /proc/kallsyms file which exposes the kernel memory space - address of many kernel symbols (functions, variables, etc.). - This information is useful to attackers in identifying kernel - versions/configurations and in preparing payloads for exploits of - kernel space. - - Both KALLSYMS\_ALL and KALLSYMS shall be disabled; - -```bash - CONFIG_KALLSYMS=n - CONFIG_KALLSYMS_ALL=n -``` - -### Disable Kernel Debugging - - There are development-only branches of code in the kernel enabled by - the DEBUG\_KERNEL conf. - This should be disabled to compile-out these branches. - -```bash - CONFIG_DEBUG_KERNEL=n -``` - - In some kernel versions, disabling this requires also disabling - CONFIG\_EMBEDDED, and CONFIG\_EXPERT Disabling CONFIG\_EXPERT makes it - impossible to disable \_COREDUMP, DEBUG\_BUGVERBOSE, \_NAMESPACES, - \_KALLSYMS and \_BUG. - In which case it is better to leave this enabled - than enable the others. - -### Disable the kernel debug filesystem - - The kernel debug filesystem presents a lot of useful information and - means of manipulation of the kernel to an attacker. - -```bash - CONFIG_DEBUG_FS=n -``` - -### Disable BUG() support - - The kernel will display backtrace and register information for BUGs - and WARNs in kernel space, making it easier for attackers to develop - exploits. - -```bash - CONFIG_BUG=n -``` - -### Disable Sysctl syscall support - - Enabling this will result in code being included that is hard to - maintain and not well tested. - -```bash - CONFIG_SYSCTL_SYSCALL=n -``` - -### Kernel Modules - -### Disable module unloading - - This stops an attacker unloading security focused kernel modules. - It will also prevent the attacker from removing evidence of any attempted - kernel tampering that may have been initiated by loading of a kernel - module. - -```bash - CONFIG_MODULE_UNLOAD=n -``` - -### Disable Forced Module Loading - - If enabled, then modules without version information or with - mismatched version information may be forcibly loaded into the kernel. - Disabling this configuration forces the attackers to build modules - with matched kernel sources and configuration in order to load them. - -```bash - CONFIG_MODULE_FORCE_LOAD=n -``` -### System Services - -#### Console & Remote Access - -- The kernel console interfaces shall be disabled. Do not pass any statements - of the following kind (e.g. console=ttyS0 console=tty0) on the kernel - command line. All of the console=<interface> statements should be - stripped and removed from the kernel command line. - -- The telnet server shall be disabled. - -- Do not start telnetd in init scripts. - -- Remove telnetd from the root file system. - -- Root login access via the console shall be disabled. - -- Do not run shell or getty on /dev/ttySx or /dev/console from - init scripts. - -- Root login access through remote access such as SSH shall - be disabled or completely removed - -#### Disable *sudo* for other users - - Remove the /etc/sudoers file from the root file system - - Remove the sudo command from the root file system. - -#### Mount /tmp file system as noexec - - A lot of malware can be stopped by not allowing files located in /tmp - to execute. - - The /etc/fstab file should contain a line for the /tmp directory with - the noexec mount option set as follows: - - tmpfs /tmp tmpfs noexec 0 0 - -#### User Account Management - - All user accounts shall have strong, non-default passwords. A strong - password is described to have all of the following attributes: - -- At least one upper-case letter - -- At least one numeric character - -- At least one lower-case letter - -- Password shall be eight or more characters in length - -- Shall not use a known, common pattern (e.g. Xxxxxxx\# - or Xxxxxxx\#\#) - -#### Remove known insecure services - - The following legacy services are inherently insecure and should be - avoided: - -- rlogind - -- rshd - -- rcmd - -- rexecd - -- rbootd - -- rquotad - -- rstatd - -- rusersd - -- rwalld - -- rhosts - -- rexd - - These services offer insufficient authentication, no encryption, and - are not considered secure. They shall be removed along with their - configuration files. - -### The mtd-utils shall not be present on the file system - - The mtd-utils binary package (also known as the Memory Technology - Device Utilities package) contains a collection of executable binaries - that allow a user to perform operations on raw flash devices. Here’s a - non-exhaustive sample of commonly used utilities that are part of the - mtd-utils package: - -- flash\_erase - -- flash\_eraseall - -- flashcp - -- flash\_lock - -- flash\_otp\_dump - -- flash\_otp\_info - -- flash\_unlock - -- mkfs.jffs2 - -- mkfs.ubifs - -- nanddump - -- nandtest - -- nandwrite - -- ubiattach - -- ubicrc32 - -- ubidetach - -- ubiformat - -- ubimkvol - -- ubinfo - -- ubinize - -- ubirename - -- ubirmvol - -- ubirsvol - -- ubiupdatevol - - The mtd-utils package as a whole (including all of its executable - binaries) shall not be present on the file system. Including these - binaries on the file system will facilitate an attacker’s ability to - read, write or otherwise gather information about raw flash devices - present on the system. - -### Debuggers shall not be present on the file system - - No debuggers shall be present on the file system. This includes, but - is not limited to, the GNU Debugger client/server (commonly known in - their short form names such as the gdb and gdbserver executable - binaries respectively), or the LLDB next generation debugger. - Including these binaries as part of the file system will facilitate an - attacker’s ability to reverse engineer and debug (either locally or - remotely) any process that is currently executing on the device. - -### Partition Mount Options - - There are several security restrictions that can be set on a - filesystem when it is mounted. Some common security options include, - but are not limited to: - - nosuid - Do not allow set-user-identifier or set-group-identifier bits - to take effect - - nodev - Do not interpret character or block special devices on the - filesystem - - noexec - Do not allow execution of any binaries on the mounted - filesystem - - ro - Mount filesystem as read-only - - The following flags shall be used for mounting common filesystems: - - -| Partition | Notes | -|------------------------------|---------------------------------------------------------------------------------------------| -| /boot | Use nosuid and nodev and consider using noexec. | -| /var & /tmp | In the /etc/fstab or vfstab file, add nosuid, nodev and noexec. | -| Non-Root local partitions | If the filesystem type is ext2 or ext3 and the mount point is not '/', add the nodev option.| -| Removable storage partitions | Add nodev, nosuid, and noexec options. | -| Temporary storage partitions | Add nodev, nosuid, and noexec options. | -| /dev/shm | Add nodev, nosuid, and noexec options. | -| /dev | Add nosuid, noexec options.\ | -| | Note: if CONFIG\_DEVTMPFS\_MOUNT is set then the kernel will mount /dev and will not apply | -| | the nosuid, noexec options. Either disable CONFIG\_DEVTMPFS\_MOUNT or add a remount with | -| | noexec and nosuid options to system startup. | - - -# Recommendations - -The following sections detail best practices that should be applied in -order to secure a device. -Although they are not currently listed as hard -requirements, they may be upgraded to requirements status in the future. -In addition, specific operators may change some of these recommendations -into requirements based on their specific needs and objectives. - -## Hardened Boot - -The boot loader consists of the Primary boot loader residing in OTP -memory, sboot, U-Boot and Secure loader residing in external flash (NAND -or SPI/NOR flash memory). The CPU on power on or reset executes the -primary boot loader. The OTP primary boot loader makes the necessary -initial system configuration and then loads the secondary boot loader -sboot from external flash memory to ram memory. The sboot then loads the -U-Boot along with the Secure loader. U-Boot then verifies and loads the -Kernel/system image before passing control to it. - -### Removal of memory dump commands - -In U-Boot, following commands shall be disabled to avoid memory dumps - -``` -md : Memory Display command - -mm : Memory modify command – auto incrementing address - -nm : Memory modify command – constant address - -mw : memory write - -cp : memory copy - -mwc : memory write cyclic - -mdc : memory display cyclic - -mtest : simple ram read/write test - -loopw : infinite write loop on address range -``` - -Similarly memory dump support shall be disabled from sboot - -### Disable flash access - -In U-Boot following flash memory commands shall be disabled: - -Nand: Support for nand flash access available through **do\_nand** has -to be disabled. - -Similarly sboot should disable flash access support through command line -if any. - -## Hardened System - -### Network - -#### Disable all Network Interfaces - - Preferably no network interface is allowed, but if required, then the - enabled services should be restricted to only those described in the - STB’s functional description. - -### Remove or Disable Unnecessary Services, Ports, and Devices. - - Services and utilities that do not have a defined purpose on a system - should be removed. If removal is not possible, but the service or - utility can be disabled, then it should be disabled. If a service or - utility is necessary, available secure configuration best practices - should be implemented. - - Telnet, FTP, and NFS have security weaknesses that are well known; - however, customers may have requirements to use these services. If - remote shell access and file transfer are required, then provide more - secure options, such as SSH and SFTP/SCP. - -### Restrict USB Ports - - Linux Kernel support for USB should be compiled-out if not required. - If it is needed, the Linux Kernel should be configured to only enable - the minimum required USB devices. - - User-initiated USB-filesystems should be treated with special care.. - - Whether or not the filesystems are mounted in userspace(FUSE), restricted - mount options should be observed. - -## Kernel Hardening - - The following sub-sections contain information on various kernel - configuration options that will require updating to a newer kernel - version in order to enhance the security measures in the kernel and - also for applications compiled to take advantage of these security - features. - - Additionally, there are also configuration options that close known - vulnerable configuration options. - Here’s a high level summary of the - various kernel configurations and which kernel version they pertain: - -| Kernel Configuration | Kernel Version | -|---------------------------------------|----------------| -| CONFIG\_UNIX\_DIAG=n |3.3+ | -| CROSS\_MEMORY\_ATTACH=n |3.5+ | -| CONFIG\_PANIC\_ON\_OOPS=y |3.5+ | -| CONFIG\_COREDUMP=n |3.7+ | -| CONFIG\_MODULE\_SIG\_FORCE=y |3.7+ | -| CONFIG\_PACKET\_DIAG=n |3.7+ | -| CONFIG\_FW\_LOADER\_USER\_HELPER=n |3.9+ | -| CONFIG\_CC\_STACKPROTECTOR=y |3.11+ | -| CONFIG\_USELIB=n |3.15+ | -| BPF\_JIT=n |3.16+ | -| CONFIG\_DEVMEM=n |4.0+ | - -### Build with Stack Protection - - Similar to the stack protector used for ELF programs in user-space, - the kernel can protect its internal stacks as well. - This configuration is supported in Linux 3.11 and greater and - thus should only be enabled for such versions. - This configuration also - requires building the kernel with the gcc compiler 4.2 or greater. - -```bash - CONFIG_CC_STACKPROTECTOR=y -``` - -### Disable access to /dev/mem - - The /dev/mem file in Linux systems is directly mapped to physical - memory. - This can be disastrous if an attacker gains root access, as - the attacker would have direct access to physical memory through this - convenient device file. - It may not always be possible to disable such - file, as some applications might need such support. - In that case then - this device file should be available only for authenticated - applications. - This configuration is supported in Linux 4.0 and greater - and thus should only be disabled for such versions. - -```bash - CONFIG_DEVMEM=n -``` - -### Disable cross-memory attach - - Disable the process\_vm\_\*v syscalls which allow one process to - peek/poke the virtual memory of another. - This configuration is - supported in Linux 3.5 and greater and thus should only be disabled - for such versions. -```bash - CROSS_MEMORY_ATTACH=n -``` - -### Disable core dumps - - Core dumps provide lot of debug information for hackers. - So disabling core dumps is recommended in production builds. - This configuration is - supported in Linux 3.7 and greater and thus should only be disabled - for such versions. - -```bash - CONFIG_COREDUMP=n -``` - -### Disable Legacy Linux Support - - There are some Kernel Configs which are present only to support legacy - binaries. - See also section 2.2.2.18 for disabling support for legacy binary formats. - The uselib system call, in particular, has no valid use in any libc6 or uclibc system in recent times. - This configuration is supported in Linux 3.15 and greater and thus should only be - disabled for such versions. - -```bash - CONFIG_USELIB=n -``` - -### Disable firmware auto-loading user mode helper - - The firmware auto loading helper, which is a utility executed by the - kernel on hotplug events requiring firmware, needs to be set setuid. - As a result of this, the helper utility is an attractive target for - attackers with control of physical ports on the device. - Disabling this configuration is supported in Linux 3.9 and greater. - -```bash - CONFIG_FW_LOADER_USER_HELPER=n -``` - -### Enable Kernel Panic on OOPS - - When fuzzing the kernel or attempting kernel exploits attackers are - likely to trigger kernel OOPSes. - Setting the behavior on OOPS to PANIC can impede their progress. - This configuration is supported in Linux 3.5 and greater and thus should only be enabled for such versions. - -```bash - CONFIG_PANIC_ON_OOPS=y -``` - -### Disable socket monitoring interface - - These monitors can be used to inspect shared file descriptors on Unix - Domain sockets or traffic on ‘localhost’ which is otherwise assumed to - be confidential. - The **CONFIG\_PACKET\_DIAG** configuration is supported in Linux 3.7 and greater and thus should only be disabled - for such versions. - The **CONFIG\_UNIX\_DIAG** configuration is - supported in Linux 3.3 and greater and thus should only be disabled - for such versions. - -```bash - CONFIG_PACKET_DIAG=n - CONFIG_UNIX_DIAG=n -``` - -### Disable BPF JIT - - The BPF JIT can be used to create kernel-payloads from firewall table - rules. - This configuration for is supported in - Linux 3.16 and greater and thus should only be disabled for such - versions. - -```bash - BPF_JIT=n -``` - -### Enable Enforced Module Signing - - This configuration is supported in Linux 3.7 and greater and thus - should only be enabled for such versions. - -```bash - CONFIG_MODULE_SIG_FORCE=y -``` - -### Disable all USB, PCMCIA (and other hotplug bus) drivers that aren’t needed - - To reduce the attack surface, the driver enumeration, probe, and - operation happen in the kernel. - The driver data is parsed by the kernel, so any logic bugs in these drivers can become kernel exploits. - -### Disable all file systems not needed - - To reduce the attack surface, file system data is parsed by the kernel - so any logic bugs in file system drivers can become kernel exploits. - -### Kernel Address Display Restriction - - When attackers try to develop "run anywhere" exploits for kernel - vulnerabilities, they frequently need to know the location of internal - kernel structures. - By treating kernel addresses as sensitive information, those locations are not visible to regular local users. - - /proc/sys/kernel/kptr\_restrict is set to "1" to block the reporting - of known kernel address leaks. - - Additionally, various files and directories should be readable only by - the root user: /boot/vmlinuz\*, /boot/System.map\*, - /sys/kernel/debug/, /proc/slabinfo - -### DMESG Restrictions - - When attackers try to develop "run anywhere" exploits for - vulnerabilties, they frequently will use dmesg output. - By treating dmesg output as sensitive information, this output is not available to - the attacker. - - /proc/sys/kernel/dmesg\_restrict can be set to "1" to treat dmesg - output as sensitive. - -Enable the below compiler and linker options when building user-space -applications to avoid stack smashing, buffer overflow attacks. - -### Stack Smashing Attacks - - **-fstack-protector-all** - - Emit extra code to check for buffer overflows, such as stack smashing - attacks - -### Position Independent Executables - - **-pie –fpic** - - Produce a position independent executable on targets which supports - it. - -### Detect Buffer Overflows - - **-D\_FORTIFY\_SOURCE=2** - - Helps detect some buffer overflow errors. - -### Prevent Overwrite Attacks - - **–z,relro** - - This linking option helps during program load, several ELF memory - sections need to be written by the linker, but can be turned read-only - before turning over control to the program. This prevents some Global - Offset Table GOT overwrite attacks, or in the dtors section of the ELF - binary. - - **-z,now** - -During program load, all dynamic symbols are resolved, allowing for the -complete GOT to be marked read-only (due to -z relro above). This -prevents GOT overwrite attacks. For very large application, this can -incur some performance loss during initial load while symbols are -resolved, but this shouldn't be an issue for daemons. - -### Library linking - - **–static** - -It is recommended that dynamic linking should not be allowed. This will -avoid user from replacing a library with malicious library. All libraries -should be linked statically. - -## Removal or Non-Inclusion of Utilities - -Table below lists utilities that are typically present in an embedded -device, along with the normal path of each utility. The table has -information about whether a utility shall be included or excluded from -respective environment. The values “INCLUDE” here means to include the -utility in the environment and “EXCLUDE” means to exclude it from the -respective environment. - -| **Utility Name** | **Location** | **Debug Environment** | **Production Environment** | -|-------------------|-------------------------------------------|------------------------|------------------------------| -| Strace | /bin/trace | INCLUDE | EXCLUDE | -| Klogd | /sbin/klogd | INCLUDE | EXCLUDE | -| Syslogd(logger) | /bin/logger | INCLUDE | EXCLUDE | -| Gdbserver | /bin/gdbserver | INCLUDE | EXCLUDE | -| Dropbear | Remove “dropbear” from ‘/etc/init.d/rcs’ | EXCLUDE | EXCLUDE | -| SSH | NA | INCLUDE | EXCLUDE | -| Editors (vi) | /bin/vi | INCLUDE | EXCLUDE | -| Dmesg | /bin/dmesg | INCLUDE | EXCLUDE | -| UART | /proc/tty/driver/ | INCLUDE | EXCLUDE | -| Hexdump | /bin/hexdump | INCLUDE | EXCLUDE | -| Dnsdomainname | /bin/dnsdomainname | EXCLUDE | EXCLUDE | -| Hostname | /bin/hostname | INCLUDE | EXCLUDE | -| Pmap | /bin/pmap | INCLUDE | EXCLUDE | -| su | /bin/su | INCLUDE | EXCLUDE | -| Which | /bin/which | INCLUDE | EXCLUDE | -| Who and whoami | /bin/whoami | INCLUDE | EXCLUDE | -| ps | /bin/ps | INCLUDE | EXCLUDE | -| lsmod | /sbin/lsmod | INCLUDE | EXCLUDE | -| install | /bin/install | INCLUDE | EXCLUDE | -| logger | /bin/logger | INCLUDE | EXCLUDE | -| ps | /bin/ps | INCLUDE | EXCLUDE | -| rpm | /bin/rpm | INCLUDE | EXCLUDE | -| Iostat | /bin/iostat | INCLUDE | EXCLUDE | -| find | /bin/find | INCLUDE | EXCLUDE | -| Chgrp | /bin/chgrp | INCLUDE | EXCLUDE | -| Chmod | /bin/chmod | INCLUDE | EXCLUDE | -| Chown | /bin/chown | INCLUDE | EXCLUDE | -| killall | /bin/killall | INCLUDE | EXCLUDE | -| top | /bin/top | INCLUDE | EXCLUDE | -| stbhotplug | /sbin/stbhotplug | INCLUDE | EXCLUDE | - -Note: The following Unix/Linux utilities 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. - - **sed, awk, cut, df, dmesg, echo, fdisk, grep, mkdir, mount (vfat), - printf, tail, tee, test (directory), test (file)** - -## 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 are 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. - -Root access **should not be allowed** for the following utilities: - -``` - login - su - ssh - scp - sftp -``` - -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. - -## Network Hardening - -### Disable IPv4 Forwarding - - The net.ipv4.ip\_forward sysctl setting controls if IP forwarding is - allowed or not on the System. Unless the system is used as a router or - gateway, IPv4 forwarding should be disabled. - -### Disable IP Source Routing - - Disable IP source routing on all interfaces through the - net.ipv4.conf.\*.accept\_source\_route = 0 setting. - - IP source routing would allow a remote user (the sender) to specify - the route that the packet should take, rather than use the (default) - routing tables used by the routers between the sender and the - destination. This could be used to spoof IP addresses and still get - the replies (rather than sending the replies to the real owner of the - IP address). - -### Disable ICMP - - Use of ICMP, especially ping, shall be avoided. This is a common way - of gaining access to a system. - -#### Disable ICMP Redirects - - Set net.ipv4.conf.\*.accept\_redirects=0 to disable ICMP redirect - support on the interfaces. - - ICMP redirect messages are used by routers to inform hosts to use a - different gateway than the one used. These packets should only be sent - by the gateway of the system. In managed and embedded devices the - gateway is controlled and any changes should be controlled. - - Allowing ICMP redirect messages would allow for "remote" updating of - the routing table, which could allow an attacker to get all packets - sent to the outside first rather than the packets immediately going to - the real gateway. - -#### Ignore ICMP Echo Broadcasts - - When net.ipv4.icmp\_echo\_ignore\_broadcasts=1 is set, then your - system will not reply to broadcast “ping” requests. - -#### Ignore ICMP Bogus Error Responses - - When an invalid response is given to broadcast frames (which occurs - sometimes in erroneous routers), the Linux kernel will by default log - this event. These can be disabled by setting - throughnet.ipv4.icmp\_ignore\_bogus\_error\_responses to 1. - -### Ignore all broadcast message - - All the IP packets that come on the address “255.255.255.255” shall be - ignored. This can be done through the iptables rules. - -### Disable IPV6 - - If there are no plans of using IPV6, it is a good practice to disable - this support as it will reduce the size of the kernel TCP/IP stack. - -### Enable TCP SYN Cookie Protection - - One way of denial of service (DoS) attack against a service would be - to flood the server with SYNrequests (the TCP packet that starts a - handshake for a connection). Such a flood can lead to a service - disruption as the connection state handling will consume significant - resources. - - By enabling net.ipv4.tcp\_syncookies, the Linux kernel will change its - handshake behavior when its SYN backlog queue overflows: it replies to - SYN requests with the appropriate SYN+ACK reply, but it does not store - the connection in its backlog queue. - - -# Validation - -## Hardened System - -### Image Security Analysis Framework (ISAFW) - -**meta-security-isafw** is an OE layer that allows enabling the Image -Security Analysis Framework (isafw) for your image builds. - -The primary purpose of isafw is to provide an extensible -framework for analysing different security aspects of images -during the build process. - -The isafw project itself can be found at - https://github.com/01org/isafw - -This layer can be added to your builds to produce an analysis report, -including a kernel config analysis. - -### Usage - -In order to enable the isafw during the image build, please add -the following line to your build/conf/local.conf file: - -```python -INHERIT += "isafw" -``` diff --git a/sec-blueprint/App-flow.png b/sec-blueprint/App-flow.png Binary files differdeleted file mode 100644 index 7b87c29..0000000 --- a/sec-blueprint/App-flow.png +++ /dev/null diff --git a/sec-blueprint/App_signing_flow.png b/sec-blueprint/App_signing_flow.png Binary files differdeleted file mode 100644 index 56a7c23..0000000 --- a/sec-blueprint/App_signing_flow.png +++ /dev/null diff --git a/sec-blueprint/index.md b/sec-blueprint/index.md deleted file mode 100644 index 776d5ed..0000000 --- a/sec-blueprint/index.md +++ /dev/null @@ -1,23 +0,0 @@ ---- - -title : Security BluePrint Overview -date : 2017-07-07 -category: security -tags: security, architecture, automotive, linux -layout: techdoc - ---- - -## [Overview](./01-overview.html) - -## [Adversaries](./02-adversaries.html) - -## [Threat Analysis](./03-threat-analysis.html) - -## [Security Concepts](./04-security-concepts.html) - -## [Plateform Security](./05-plateform-security.html) - -## [Application Security](./06-application-security.html) - -## [System Hardening](./07-system-hardening.html) |
