From 9cc56459419f1225f5e9851825ad305424b3d6fb Mon Sep 17 00:00:00 2001 From: Shankho Boron Ghosh Date: Wed, 18 Nov 2020 19:55:02 +0530 Subject: Revision of Architecture Guides v1: Introduction : Skeleton file of Build Process [WIP]. Security Blueprint : Multiple markdowns appended into single markdown. v2: Security Blueprint : 4_Kernel.md - Fixed Internal Link. Annexes.md - Uniform markdown Title. Bug-AGL: [SPEC-3633] Signed-off-by: Shankho Boron Ghosh Change-Id: I1ab478348a05464612d67f0e8a4570bda309022d Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25586 Reviewed-by: Jan-Simon Moeller Tested-by: Jan-Simon Moeller --- docs/2_Architecture_Guides/0_Build_Process.md | 5 - .../1_Introduction/0_Build_Process.md | 3 + .../1_AGL_Requirements_Specifications.md | 5 + .../AGL Requirements Specifications.pdf | Bin 0 -> 3801991 bytes .../AGL Requirements Specifications.md | 1 - .../AGL Requirements Specifications.pdf | Bin 3801991 -> 0 bytes .../0_Introduction/Introduction.md | 275 ------ .../0_Introduction/WhiteBoxArchi.png | Bin 348110 -> 0 bytes .../10_Annexes/1.2.10.0_Abstract.md | 11 - .../10_Annexes/1.2.10.1_Config_Notes.md | 489 ----------- .../10_Annexes/1.2.10.2_To_Do_Notes.md | 84 -- .../2.2_Security_Blueprint/1_Hardware/Abstract.md | 82 -- .../2_Secure_Boot/1.2.2.0_Abstract.md | 69 -- .../2_Secure_Boot/1.2.2.1_Image.md | 56 -- .../2_Secure_Boot/1.2.2.2_Communication-modes.md | 94 -- .../2_Secure_Boot/1.2.2.3_Consoles.md | 111 --- .../3_Hypervisor/Abstract.md | 23 - .../4_Kernel/1.2.4.0_Abstract.md | 65 -- .../4_Kernel/1.2.4.1_General.md | 322 ------- .../4_Kernel/1.2.4.2_Memory.md | 182 ---- .../4_Kernel/1.2.4.3_Consoles.md | 99 --- .../4_Kernel/1.2.4.4_Debug.md | 251 ------ .../4_Kernel/1.2.4.5_FileSystems.md | 71 -- .../5_Platform/1.2.5.0_Abstract.md | 111 --- .../5_Platform/1.2.5.1_Mandatory_Access_Control.md | 176 ---- .../5_Platform/1.2.5.2_SystemD.md | 64 -- .../5_Platform/1.2.5.3_SystemBus.md | 30 - .../5_Platform/1.2.5.4_Services.md | 41 - .../5_Platform/1.2.5.5_Application_framework.md | 357 -------- .../5_Platform/1.2.5.6_Utilities.md | 82 -- .../5_Platform/1.2.5.7_Users.md | 82 -- .../2.2_Security_Blueprint/5_Platform/App-flow.png | Bin 73545 -> 0 bytes .../6_Application/1.2.6.0_Abstract.md | 89 -- .../6_Application/1.2.6.1_Installation.md | 33 - .../6_Application/1.2.6.2_Privilege_Management.md | 11 - .../6_Application/1.2.6.3_Signature.md | 13 - .../6_Application/1.2.6.4_Services.md | 14 - .../6_Application/App_signing_flow.png | Bin 154923 -> 0 bytes .../7_Connectivity/1.2.7.0_Abstract.md | 56 -- .../7_Connectivity/1.2.7.1_Bus_And_Connectors.md | 75 -- .../7_Connectivity/1.2.7.2_Wireless.md | 261 ------ .../7_Connectivity/1.2.7.3_Cloud.md | 111 --- .../8_Update_(Over_The_Air)/1.2.8.0_Abstract.md | 94 -- .../1.2.8.1_Firmware_Over_The_Air.md | 49 -- .../1.2.8.2_Software_Over_The_Air.md | 25 - .../9_Secure_development/1.2.9.0_Abstract.md | 72 -- .../2_Security_Blueprint/0_Overview.md | 250 ++++++ .../2_Security_Blueprint/1_Hardware.md | 64 ++ .../2_Security_Blueprint/2_Secure_Boot.md | 261 ++++++ .../2_Security_Blueprint/3_Hypervisor.md | 17 + .../2_Security_Blueprint/4_Kernel.md | 941 +++++++++++++++++++++ .../2_Security_Blueprint/5_Platform.md | 921 ++++++++++++++++++++ .../2_Security_Blueprint/6_Application.md | 125 +++ .../2_Security_Blueprint/7_Connectivity.md | 487 +++++++++++ .../2_Security_Blueprint/8_Update_OTA.md | 154 ++++ .../2_Security_Blueprint/9_Secure_development.md | 58 ++ .../2_Security_Blueprint/Annexes.md | 578 +++++++++++++ .../2_Security_Blueprint/images/App-flow.png | Bin 0 -> 73545 bytes .../images/App_signing_flow.png | Bin 0 -> 154923 bytes .../2_Security_Blueprint/images/WhiteBoxArchi.png | Bin 0 -> 348110 bytes 60 files changed, 3864 insertions(+), 4136 deletions(-) delete mode 100644 docs/2_Architecture_Guides/0_Build_Process.md create mode 100644 docs/2_Architecture_Guides/1_Introduction/0_Build_Process.md create mode 100644 docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md create mode 100644 docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf delete mode 100644 docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.md delete mode 100644 docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.pdf delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/Introduction.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/WhiteBoxArchi.png delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.0_Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.1_Config_Notes.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.2_To_Do_Notes.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/1_Hardware/Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.1_Image.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.2_Communication-modes.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.3_Consoles.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/3_Hypervisor/Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.1_General.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.2_Memory.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.3_Consoles.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.4_Debug.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.5_FileSystems.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.1_Mandatory_Access_Control.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.2_SystemD.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.3_SystemBus.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.4_Services.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.6_Utilities.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/App-flow.png delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.1_Installation.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.2_Privilege_Management.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.3_Signature.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.4_Services.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/App_signing_flow.png delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.0_Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.1_Bus_And_Connectors.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.2_Wireless.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.3_Cloud.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.0_Abstract.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.1_Firmware_Over_The_Air.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.2_Software_Over_The_Air.md delete mode 100644 docs/2_Architecture_Guides/2.2_Security_Blueprint/9_Secure_development/1.2.9.0_Abstract.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png create mode 100644 docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png (limited to 'docs') diff --git a/docs/2_Architecture_Guides/0_Build_Process.md b/docs/2_Architecture_Guides/0_Build_Process.md deleted file mode 100644 index dba54c3..0000000 --- a/docs/2_Architecture_Guides/0_Build_Process.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Overview ---- - - diff --git a/docs/2_Architecture_Guides/1_Introduction/0_Build_Process.md b/docs/2_Architecture_Guides/1_Introduction/0_Build_Process.md new file mode 100644 index 0000000..7137deb --- /dev/null +++ b/docs/2_Architecture_Guides/1_Introduction/0_Build_Process.md @@ -0,0 +1,3 @@ +--- +title: Overview +--- diff --git a/docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md b/docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md new file mode 100644 index 0000000..51946b8 --- /dev/null +++ b/docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md @@ -0,0 +1,5 @@ +--- +title: AGL Requirements Specifications +--- + +[**AGL Requirements Specifications PDF**](AGL Requirements Specifications.pdf) diff --git a/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf b/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf new file mode 100644 index 0000000..c5be950 Binary files /dev/null and b/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf differ diff --git a/docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.md b/docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.md deleted file mode 100644 index 6ec22d7..0000000 --- a/docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.md +++ /dev/null @@ -1 +0,0 @@ -[**AGL Requirements Specifications**](AGL Requirements Specifications.pdf) diff --git a/docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.pdf b/docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.pdf deleted file mode 100644 index c5be950..0000000 Binary files a/docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.pdf and /dev/null differ diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/Introduction.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/Introduction.md deleted file mode 100644 index b4ccf37..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/Introduction.md +++ /dev/null @@ -1,275 +0,0 @@ ---- -title: Introduction ---- - -# Introduction - -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. - -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. - -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. - -Security domains will allow us to create a set of tests verifying the security -of Automotive Grade Linux. - -This document is firstly based on an existing AGL security-blueprint. - -**For security to be effective, the concepts must be simple. And by default, -anything that is not allowed is forbidden.** - -We will cover topics starting from the lowest level (_Hardware_) up to the -highest levels (_Connectivity_ and _Application_). We will move quickly on -_Hardware_ and _Connectivity_ because this is not supported at our level. -Solutions of connectivity problems concern updates and secured settings while -hardware securing is related to the manufacturers. - -The document is filled with tags to easily identify important points: - - - -- The _config_ tag quickly identifies the configurations and the recommendations - to take. - - - -- The _note_ tag allows you to notify some additional details. - - - -- The _todo_ tag shows the possible improvements. - - - -In annexes of this document, you can find all the _config_ and _todo_ notes. - -## Adversaries - -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 automotive 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. - -## 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) | - -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. - -## 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 -prioritization of the the assets in a concrete vehicle network can be achieved -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 | | | - -## Hardening term - -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 devices. 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. - - - -## AGL security overview - -AGL roots are based on security concepts. Those concepts are implemented by the -security framework as shown in this picture: - -![AGL architecture](WhiteBoxArchi.png) - --------------------------------------------------------------------------------- - -# Acronyms and Abbreviations - -The following table lists the strongest terms utilized within all this document. - -| Acronyms or Abbreviations | Description | -|---------------------------|-------------------------------------| -| _AGL_ | **A**utomotive **G**rade **L**inux | -| _ECU_ | **E**lectronic **C**ontrol **U**nit | - --------------------------------------------------------------------------------- - - - -# References - -- [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html). - - _http:// - docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html_ -- **[2017]** - [kernel - security](https://www.kernel.org/doc/Documentation/security/). - - _https:// www.kernel.org/doc/Documentation/security/_ -- **[2017]** - [Systemd integration and user - management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf). - - _http:// iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf_ -- **[2017]** - [AGL - Application Framework - Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf). - - _http:// iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf_ -- **[2017]** - [Improving Vehicle - Cybersecurity](https://access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf). - - _https:// - access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf_ -- **[2016]** - [AGL framework - overview](http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html). - - _http:// - docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html_ -- **[2016]** - - [SecureBoot-SecureSoftwareUpdates](http://iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf). - - _http:// - iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf_ -- **[2016]** - [Linux Automotive - Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf). - - _http:// - iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf_ -- **[2016]** - [Automotive Security Best - Practices](https://www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf). - - _https:// - www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf_ -- **[2016]** - [Gattacking Bluetooth Smart - Devices](http://gattack.io/whitepaper.pdf). - - _http:// gattack.io/whitepaper.pdf_ -- **[2015]** - [Comprehensive Experimental Analysis of Automotive Attack - Surfaces](http://www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf). - - _http:// - www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf_ -- **[2015]** - [Security in Automotive Bus - Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf). - - _http:// - citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf_ -- **[2014]** - [IOActive Remote Attack - Surface](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf). - - _https:// www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf_ -- **[2011]** - [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data - communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf). - - _https:// - media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf_ -- **[2011]** - [Comprehensive Experimental Analyses of Automotive Attack - Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf). - - _http:// www.autosec.org/pubs/cars-usenixsec2011.pdf_ -- **[2010]** - [Relay Attacks on Passive Keyless Entry and Start Systems in - Modern Cars](https://eprint.iacr.org/2010/332.pdf). - - _https:// eprint.iacr.org/2010/332.pdf_ -- **[2010]** - [Wifi attacks wep - wpa](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf). - - _https:// matthieu.io/dl/wifi-attacks-wep-wpa.pdf_ -- **[2008]** - - [SMACK](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf). - - _http:// - schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf_ diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/WhiteBoxArchi.png b/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/WhiteBoxArchi.png deleted file mode 100644 index d984d1a..0000000 Binary files a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/WhiteBoxArchi.png and /dev/null differ diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.0_Abstract.md deleted file mode 100644 index bf4e936..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.0_Abstract.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Annexes ---- - -# Annexes - -The first part resumed all the configurations you must implement without any -explications since all the explanations are given as and when in the document. - -The second one allows to visualize all the todo notes in order to have a global -vision of the possible improvements of the document. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.1_Config_Notes.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.1_Config_Notes.md deleted file mode 100644 index 293b6f3..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.1_Config_Notes.md +++ /dev/null @@ -1,489 +0,0 @@ ---- -title: Config notes ---- - -# Config notes - - -Domain | Object | Recommendations --------------------- | ---------- | ---------------------------------- -Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. -Hardware-Integrity-2 | Board | Must use a HSM. -Hardware-Integrity-3 | RTC | Must not be alterable. - -Domain | Object | Recommendations ----------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. -Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. -Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. - -Domain | Object | Recommendations ------------------ | ---------- | ------------------------------------------------------------------------------------ -Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. -Hardware-Memory-2 | Bootloader | Internal NVM only -Hardware-Module-3 | - | HSM must be used to secure keys. - -Domain | _Variable_ / `Config` name | `Value` ----------------------- | -------------------------- | ------- -Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` -Boot-Image-Selection-2 | _bootdelay_ | `-2` - -Domain | `Config` name | _State_ -------------------------- | ---------------------------- | -------- -Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ -Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ -Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ -Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ -Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ -Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ - -Domain | Communication modes | _State_ --------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- -Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. -Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. -Boot-Communication-3 | `Ethernet` | _Disabled_ -Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ -Boot-Communication-5 | `Serial ports` | _Disabled_ - -Domain | `Config` name | _State_ ------------------------- | ----------------------- | ------------- -Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ -Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ -Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ -Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ -Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ - -Domain | Communication modes | _State_ --------------------- | -------------------- | --------------------------------------------------------------------------------------------- -Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. - -Domain | Object | Recommendations --------------------- | --------------------------------- | ------------------------------------------------------------- -Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. - -Domain | `Command` name | _State_ --------------------------- | -------------- | --------- -Boot-Communication-Flash-1 | `do_nand` | _Disable_ - -Domain | `Config` name | `Value` ----------------------- | --------------------------------------- | --------- -Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` -Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` -Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` - -Domain | `Environment variable` name | _State_ ----------------------- | --------------------------- | ------------- -Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ - -Domain | `Config` name | _State_ --------------------------- | ---------------------------- | --------- -Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` -Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` -Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` -Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` -Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` -Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` -Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` -Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` -Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` -Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` -Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` -Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` - -Domain | `Command` name | _State_ ------------------------ | -------------- | ---------- -Boot-Consoles-MemDump-1 | `md` | _Disabled_ -Boot-Consoles-MemDump-2 | `mm` | _Disabled_ -Boot-Consoles-MemDump-3 | `nm` | _Disabled_ -Boot-Consoles-MemDump-4 | `mw` | _Disabled_ -Boot-Consoles-MemDump-5 | `cp` | _Disabled_ -Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ -Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ -Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ -Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ - -Domain | `Config` name | `Value` --------------------- | -------------- | -------------------------------------- -Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m -Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m -Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y -Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y -Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y -Kernel-General-MAC-6 | CONFIG_SECURITY | y -Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y -Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y - -Domain | `Config` name | `Value` ----------------------- | -------------- | ------- -Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` - -Domain | `Config` name | `Value` ---------------------------- | --------------- | ------- -Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` - -Domain | `Config` name | `Value` -------------------------------- | ----------------------- | ------- -Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` - -Domain | `Config` name | `Value` ----------------------------- | --------------- | ------- -Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` - -Domain | `Config` name | `Value` ---------------------------- | ------------------------------ | ------- -Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` - -Domain | `Config` name | `Value` ----------------------------- | ---------------------- | ------- -Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y` - -Domain | `Config` name | `Value` --------------------------- | -------------------- | ------- -Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` -Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n` - -Domain | `Config` name | `Value` ------------------------- | ---------------- | ------- -Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` - -Domain | `Config` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` - -Domain | `Variable` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` - -Domain | Object | _State_ ------------------------- | ------------------- | ---------- -Kernel-General-Drivers-1 | `USB` | _Disabled_ -Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ -Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ - -Domain | `compiler` and `linker` options | _State_ --------------------------------- | ------------------------------- | -------- -Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ - -Domain | `compiler` and `linker` options | _State_ ---------------------------------- | ------------------------------- | -------- -Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ -Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ - -Domain | Object | Recommendations -------------------------------- | --------------- | -------------------------------- -Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. - -Domain | `Config` name | `Value` ------------------------------- | ---------------- | ------- -Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` - -Domain | `Config` name | `Value` ------------------------- | ------------------- | ------- -Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` - -Domain | `Config` name | `Value` --------------------- | ------------- | ------- -Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` -Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` - -Domain | `Config` name | `Value` ---------------------- | -------------------------- | ------- -Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n` - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` - -Domain | `compiler` and `linker` options | _State_ ------------------------------ | ------------------------------- | -------- -Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ - -Domain | `compiler` options and `config` name | `Value` -------------------------------- | ------------------------------------ | ------- -Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` -Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` - -Domain | `Config` name | `Value` ------------------------- | ---------------------------- | ------- -Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` -Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` -Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` -Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` - -Domain | `Config` name | `Value` ------------------------------ | ------------------------- | ----------------------------------- -Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` -Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` -Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` - -Domain | `Config` name | `Value` ----------------------- | ------------- | ------- -Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` - -Domain | `Config` name | `Value` ------------------------ | -------------------- | ------- -Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` - -Domain | `Config` name | `Value` ------------------------------- | -------------------- | ------- -Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` - -Domain | `Config` name | `Value` ----------------------- | ------------------- | ------- -Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n` - -Domain | `Config` name | `Value` ----------------------- | ---------------- | ------- -Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` - -Domain | `Config` name | `Value` ------------------------- | ------------------ | ------- -Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` -Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` - -Domain | `Config` name | `Value` ------------------------- | ------------------------- | ------- -Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` - -Domain | `Config` name | `Value` ------------------- | --------------------- | ------- -Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` -Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n` - -Domain | `Config` name | `Value` -------------------------- | ----------------- | ------- -Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` - -Domain | `Config` name | `Value` ------------------- | ------------- | ------- -Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` - -Domain | `Config` name | `Value` ------------------------- | ----------------- | ------- -Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` - -Domain | `File` name | `Value` ----------------------------- | -------------------------------- | ------- -Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` - -Domain | `File` or `Directorie` name | _State_ ----------------------------- | --------------------------- | ----------------------------- -Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ - -Domain | `File` name | `Value` --------------------- | --------------------------------- | ------- -Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` - -Domain | `Config` name | `Value` ---------------------- | ----------------- | ------- -Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` - -Domain | `Config` name | `Value` ------------------------- | --------------- | ------- -Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` -Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` - -Domain | `Partition` | `Value` --------------------------- | ------------------- | ----------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. -Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. - -Domain | `Config` name | _State_ or `Value` --------------------------- | ----------------------- | ----------------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. - -Domain | `Label` name | Recommendations ------------------- | ------------ | ----------------------------------------------------------- -Kernel-MAC-Floor-1 | `^` | Only for privileged system services. -Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. - -Domain | `Label` name | Recommendations -------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. -Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. -Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. -Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. -Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. - -Domain | `Label` name | Recommendations -------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. -Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. -Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. - -Domain | Object | Recommendations ------------------- | -------------- | ------------------------------------ -Platform-SystemD-1 | Security model | Use Namespaces for containerization. -Platform-SystemD-2 | Security model | Use CGroups to organise processes. - -Domain | Object | Recommendations ---------------- | -------------- | ------------------------------------ -Platform-DBus-1 | Security model | Use D-Bus as IPC. -Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) - -Domain | `Tool` name | _State_ --------------------- | ----------- | ------- -Platform-Utilities-1 | `connman` | _Used_ as a connection manager. -Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. -Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. -Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. - -Domain | Object | Recommendations ----------------------- | -------------- | -------------------------------- -Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. - -Domain | Object | Recommendations ------------------------ | ----------- | ------------------------------------- -Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. - -Domain | `Tool` name | _State_ --------------------- | ----------- | ---------------------------------------------------------------------- -Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. - -Domain | `Utility` name and normal `path` | _State_ ---------------------- | ---------------------------------------------------- | ---------- -Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ -Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ -Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ -Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ -Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ -Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ -Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ -Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ -Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ -Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ -Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ -Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ -Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ -Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ -Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ -Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ -Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ -Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ -Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ -Platform-Utilities-22 | `SSH` | _Disabled_ -Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ -Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ -Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ -Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ -Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ -Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ -Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ -Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ -Platform-Utilities-31 | `awk` (busybox) | _Enabled_ -Platform-Utilities-32 | `cut` (busybox) | _Enabled_ -Platform-Utilities-33 | `df` (busybox) | _Enabled_ -Platform-Utilities-34 | `echo` (busybox) | _Enabled_ -Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ -Platform-Utilities-36 | `grep` (busybox) | _Enabled_ -Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ -Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ -Platform-Utilities-39 | `printf` (busybox) | _Enabled_ -Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ -Platform-Utilities-41 | `tail` (busybox) | _Enabled_ -Platform-Utilities-42 | `tee` (busybox) | _Enabled_ -Platform-Utilities-43 | `test` (busybox) | _Enabled_ - -Domain | Object | Recommendations ---------------------- | ---------------- | ----------------------------------------------------- -Platform-Users-root-1 | Main application | Should not execute as root. -Platform-Users-root-2 | UI | Should run in a context on a user with no capability. - -Domain | `Utility` name | _State_ ---------------------- | -------------- | ------------- -Platform-Users-root-3 | `login` | _Not allowed_ -Platform-Users-root-4 | `su` | _Not allowed_ -Platform-Users-root-5 | `ssh` | _Not allowed_ -Platform-Users-root-6 | `scp` | _Not allowed_ -Platform-Users-root-7 | `sftp` | _Not allowed_ - -Domain | Object | Recommendations --------------------------- | --------- | ----------------------------------------------------------------------- -Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. -Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. - -Domain | Tech name | Recommendations ----------------------------------- | --------- | -------------------------------------------------------------------------- -Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. - -Domain | Tech name | Recommendations ------------------------------------------ | --------- | ---------------------------------------------------------------------- -Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. -Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. -Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. -Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. - -Domain | Object | Recommendations ------------------------ | ------ | ------------------------------------------------------------------ -Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. - -Domain | Tech name or object | Recommendations ----------------------------- | ------------------- | ------------------------------------------------------------------------- -Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled -Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used -Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. -Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. -Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. - -Domain | Tech name | Recommendations ---------------------------------- | ------------- | ------------------------------------------------------------ -Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. -Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring -Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. -Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. -Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. - -Domain | Tech name | Recommendations --------------------------------- | --------- | -------------------------- -Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid -Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. - -Domain | Tech name | Recommendations ------------------------------ | --------- | -------------------------------------------- -Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. - -Domain | Tech name | Recommendations ---------------------------- | --------- | ------------------------------------------------------ -Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. -Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. - -Domain | Object | Recommendations ----------------------------- | -------------- | -------------------------------------- -Application-Cloud-Download-1 | authentication | Must implement authentication process. -Application-Cloud-Download-2 | Authorization | Must implement Authorization process. - -Domain | Object | Recommendations ----------------------------------- | ------------- | ---------------------------------------------------------- -Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. -Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. -Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. -Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). -Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. - -Domain | Object | Recommendations ------------------------------ | ----------------------------------------- | --------------------------------- -Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.2_To_Do_Notes.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.2_To_Do_Notes.md deleted file mode 100644 index 2f68994..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.2_To_Do_Notes.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Todo notes ---- - -# Todo notes - - -Domain | Improvement ---------------- | ---------------------------------------------------- -Boot-Abstract-1 | More generic and add examples (The chain of trust). - -Domain | Improvement ---------------- | ------------------------------------------- -Boot-Abstract-1 | Review the definition of the "boot loader". - -Domain | Improvement ---------------- | ------------------------------------ -Boot-Consoles-1 | Secure loader: No reference earlier? - -Domain | Improvement ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). - -Domain | Improvement --------------------------------- | ----------------------------- -Kernel-General-IndependentExec-1 | Kernel or/and platform part ? - -Domain | Improvement -------------------------------- | --------------- -Kernel-General-LibraryLinking-1 | Keep this part? - -Domain | Improvement -------------------- | -------------------------------- -Platform-Abstract-1 | Create a graphics and sound part. - -Domain | Improvement -------------------- | ----------- -Platform-Services-1 | SystemD ? -Platform-Services-2 | Secure daemon ? - -Domain | Improvement ------------------------------ | ------------------------ -Platform-Users-Capabilities-1 | Kernel or Platform-user? -Platform-Users-Capabilities-2 | Add config note. - -Domain | Improvement --------------------------- | ------------------------------ -Application-Installation-1 | Talk about AppFw offline mode. - -Domain | Improvement ------------------------ | ---------------------------------------------------------- -Application-Signature-1 | Add content (see secure build in Secure development part). - -Domain | Improvement ----------------------- | ------------ -Application-Services-1 | Add content (Which services?). -Application-Services-2 | Add Binder. - -Domain | Improvement ------------------------ | ----------------- -Connectivity-Abstract-1 | Improve abstract. - -Domain | Improvement ------------------------ | ------------------------------------------- -Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). - -Domain | Improvement -------------- | ----------------- -Update-SOTA-1 | Part to complete. - -Domain | Improvement ------------------------ | ------------ -SecureDev-SecureBuild-1 | Add content. - -Domain | Improvement ----------------------- | ------------ -SecureDev-Signatures-1 | Add content. - -Domain | Improvement ---------------------- | ----------------------------------------------------- -SecureDev-CodeAudit-1 | Add CVE analyser. -SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/1_Hardware/Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/1_Hardware/Abstract.md deleted file mode 100644 index 7fe806f..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/1_Hardware/Abstract.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Introduction ---- - -# Part 1 - Hardware - -## Abstract - -The Automotive Grade Linux 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. - -You will find in this first part everything that concerns the hardware security. -The goal is to protect system against all attacks that are trying to gain -additional privileges by recovering and/or changing cryptographic keys in order -to alter the integrity of the boot. We should also prevent hardware -modifications in order to achieve this goal. We will expose below some examples -of possible configurations. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | -------------------------------------- -_HSM_ | **H**ardware **S**ecurity **M**odule -_NVM_ | **N**on-**V**olatile **M**emory -_SHE_ | **S**ecure **H**ardware **E**xtensions - --------------------------------------------------------------------------------- - -## Integrity - -The board must store hardcoded cryptographic keys in order to verify among -others the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and -**SHE** to enhance the security of their board. - - - -Domain | Object | Recommendations --------------------- | ---------- | ---------------------------------- -Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. -Hardware-Integrity-2 | Board | Must use a HSM. -Hardware-Integrity-3 | RTC | Must not be alterable. - - - --------------------------------------------------------------------------------- - - - -## Certificates - - - -Domain | Object | Recommendations ----------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. -Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. -Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. - - - --------------------------------------------------------------------------------- - -## Memory - - - -Domain | Object | Recommendations ------------------ | ---------- | ------------------------------------------------------------------------------------ -Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. -Hardware-Memory-2 | Bootloader | Internal NVM only -Hardware-Module-3 | - | HSM must be used to secure keys. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md deleted file mode 100644 index 73a0cab..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Introduction ---- - -# Part 2 - Secure boot - -## Abstract - - - -Domain | Improvement ---------------- | ---------------------------------------------------- -Boot-Abstract-1 | More generic and add examples (The chain of trust). - - - -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. - -**Boot Hardening**: Steps/requirements to configure the boot sequence, in order -to restrict the device from executing anything other than the approved software -image. - -In this part, we will see a series of settings that will allow us to improve -security during boot phase. 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. If the integrity is not checked or if a critical error -occurs, the system must boot on a very stable backup image. - -**Requirements**: These requirements must be met even if an alternative version -of the Linux kernel is chosen. - -**Recommendations**: Detailed 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. - - - -Domain | Improvement ---------------- | ------------------------------------------- -Boot-Abstract-1 | Review the definition of the "boot loader". - - - -**Boot loader**: 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 the Kernel/system image integrity, then loads the -Kernel/system image before passing control to it. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | ----------------------------------------------------------------------- -_FUSE_ | **F**ilesystem in **U**ser**S**pac**E** -_OTP_ | **O**ne-**T**ime-**P**rogrammable -_DOCSIS_ | **D**ata **O**ver **C**able **S**ervice **I**nterface **S**pecification diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.1_Image.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.1_Image.md deleted file mode 100644 index ad9b577..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.1_Image.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Image ---- - -# Image - -## Image selection - -The boot process shall be uninterruptible 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_. - - - -Domain | _Variable_ / `Config` name | `Value` ----------------------- | -------------------------- | ------- -Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` -Boot-Image-Selection-2 | _bootdelay_ | `-2` - - - --------------------------------------------------------------------------------- - -## Image authenticity - -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 verification. -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. - - - -Domain | `Config` name | _State_ -------------------------- | ---------------------------- | -------- -Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ -Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ -Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ -Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ -Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ -Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.2_Communication-modes.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.2_Communication-modes.md deleted file mode 100644 index fc3ea47..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.2_Communication-modes.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Communication modes ---- - -# Communication modes - -## Disable USB, Serial and DOCSIS Support - -To disable USB support in U-Boot, following config's 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. -``` - -In addition, disable unnecessary communication modes like Ethernet, Serial -ports, DOCSIS in U-Boot and sboot that are not necessary. - -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. - - - -Domain | Communication modes | _State_ --------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- -Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. -Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. -Boot-Communication-3 | `Ethernet` | _Disabled_ -Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ -Boot-Communication-5 | `Serial ports` | _Disabled_ - - - -Domain | `Config` name | _State_ ------------------------- | ----------------------- | ------------- -Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ -Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ -Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ -Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ -Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ - - - --------------------------------------------------------------------------------- - -## Disable all unused Network Interfaces - -Only used network interfaces should be enabled. Where possible, services should -also be limited to those necessary. - - - -Domain | Communication modes | _State_ --------------------- | -------------------- | --------------------------------------------------------------------------------------------- -Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. - - - -## Remove or Disable Unnecessary Services, Ports, and Devices - -Restrict the `services`, `ports` and `devices` to those used. - - - -Domain | Object | Recommendations --------------------- | --------------------------------- | ------------------------------------------------------------- -Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. - - - -## Disable flash access - -**Recommendation**: - -In U-Boot following flash memory commands shall be disabled: - -**NAND**: Support for nand flash access available through `do_nand` has to be -disabled. - - - -Domain | `Command` name | _State_ --------------------------- | -------------- | --------- -Boot-Communication-Flash-1 | `do_nand` | _Disable_ - - - -Similarly sboot should disable flash access support through command line if any. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.3_Consoles.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.3_Consoles.md deleted file mode 100644 index 0afb6f6..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.3_Consoles.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Consoles ---- - -# Consoles - -## Disable serial console - -Serial console output shall be disabled. To disable console output in U-Boot, -set the following macros: - - - -Domain | `Config` name | `Value` ----------------------- | --------------------------------------- | --------- -Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` -Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` -Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` - - - -Domain | Improvement ---------------- | ------------------------------------ -Boot-Consoles-1 | Secure loader: No reference earlier? - - - -And set "**silent**" environment variable. For the Secure loader, -disable the traces by not defining the below macro: - - - -Domain | `Environment variable` name | _State_ ----------------------- | --------------------------- | ------------- -Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ - - - -For sboot proper configuration needs to be done to disable the serial console. - --------------------------------------------------------------------------------- - - - -## 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 the 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: - - - -Domain | `Config` name | _State_ --------------------------- | ---------------------------- | --------- -Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` -Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` -Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` -Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` -Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` -Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` -Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` -Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` -Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` -Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` -Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` -Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` - - - --------------------------------------------------------------------------------- - - - -## (Recommendation) 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. -``` - - - -Domain | `Command` name | _State_ ------------------------ | -------------- | ---------- -Boot-Consoles-MemDump-1 | `md` | _Disabled_ -Boot-Consoles-MemDump-2 | `mm` | _Disabled_ -Boot-Consoles-MemDump-3 | `nm` | _Disabled_ -Boot-Consoles-MemDump-4 | `mw` | _Disabled_ -Boot-Consoles-MemDump-5 | `cp` | _Disabled_ -Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ -Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ -Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ -Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ - - - -Similarly, memory dump support shall be disabled from sboot. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/3_Hypervisor/Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/3_Hypervisor/Abstract.md deleted file mode 100644 index 7cc3017..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/3_Hypervisor/Abstract.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Introduction ---- - -# Part 3 - Hypervisor - -Definition: "A hypervisor or virtual machine monitor (VMM) is computer software, -firmware or hardware that creates and runs virtual machines". - -It must include a signature verification (possibly delegated). - - - -Domain | Improvement ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). - - - -## Native or Bare-metal hypervisors - -These hypervisors run directly on the host's hardware to control the hardware -and to manage guest operating systems. Those are the ones we're interested in. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md deleted file mode 100644 index 4f23b13..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Introduction ---- - -# Part 4 - Kernel - -## Abstract - -**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. - -At the Kernel level, we must ensure that no console can be launched. It could be -used to change the behavior of the system or to have more information about it. -Another aspect is the protection of the memory used by the Kernel. - -The next sub-sections contain information on various kernel configuration -options to enhance the security in the kernel (3.10.17) and also for -applications compiled to take advantage of these security features. -Additionally, there are also configuration options that protect from known -vulnerable configuration options. Here's a high level summary of various kernel -configurations that shall be required for deployment. - -## 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. 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. -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 verification 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 this -section. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.1_General.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.1_General.md deleted file mode 100644 index dc685bf..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.1_General.md +++ /dev/null @@ -1,322 +0,0 @@ ---- -title: General ---- - -# General configuration - -## Mandatory Access Control - -Kernel should controls access with labels and policy. - - - -Domain | `Config` name | `Value` --------------------- | -------------- | -------------------------------------- -Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m -Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m -Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y -Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y -Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y -Kernel-General-MAC-6 | CONFIG_SECURITY | y -Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y -Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y - - - -Please also refer to the [**Mandatory Access Control** documentation in -Platform](../part-5/1-MAC.html) part. You can also find useful documentation and -links on wikipedia about -[**MAC**](https://en.wikipedia.org/wiki/Mandatory_access_control) and about -[**SMACK**](https://en.wikipedia.org/wiki/Simplified_Mandatory_Access_Control_Kernel). - --------------------------------------------------------------------------------- - -## Disable kexec - -**Kexec** is a system call that enables you to load and boot into another kernel -from the currently running kernel. This feature is not required in a production -environment. - - - -Domain | `Config` name | `Value` ----------------------- | -------------- | ------- -Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` - - - - - -**kexec** can load arbitrary kernels but signing of new kernel can be enforced -like it is can be enforced for new modules. - - - --------------------------------------------------------------------------------- - -## Disable kernel IP auto-configuration - -It is preferable to have an 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. - - - -Domain | `Config` name | `Value` ---------------------------- | --------------- | ------- -Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` - - - --------------------------------------------------------------------------------- - -## Disable Sysctl syscall support - -Enabling this will result in code being included that is hard to maintain and -not well tested. - - - -Domain | `Config` name | `Value` -------------------------------- | ----------------------- | ------- -Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` - - - --------------------------------------------------------------------------------- - -## Disable Legacy Linux Support - -There are some Kernel Configs which are present only to support legacy binaries. -See also "Consoles" part in order to 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. - - - -Domain | `Config` name | `Value` ----------------------------- | --------------- | ------- -Kernel-General-LegacyLinux-1 | `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, can 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 that is supported in -**Linux 3.9 and greater**. - - - -Domain | `Config` name | `Value` ---------------------------- | ------------------------------ | ------- -Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` - - - - - -It doesn't strictly need to be `setuid`, there is an option of shipping firmware -builtin into kernel without initrd/filesystem. - - - --------------------------------------------------------------------------------- - -## 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. - - - -Domain | `Config` name | `Value` ----------------------------- | ---------------------- | ------- -Kernel-General-PanicOnOOPS-1 | `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. - - - -Domain | `Config` name | `Value` --------------------------- | -------------------- | ------- -Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` -Kernel-General-SocketMon-2 | `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. - - - -Domain | `Config` name | `Value` ------------------------- | ---------------- | ------- -Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` - - - --------------------------------------------------------------------------------- - -## Enable Enforced Module Signing - -The kernel should never allow an unprivileged user the ability to load specific -kernel modules, since that would provide a facility to unexpectedly extend the -available attack surface. - -To protect against even privileged users, systems may need to either disable -module loading entirely, or provide signed modules (e.g. -`CONFIG_MODULE_SIG_FORCE`, or dm-crypt with LoadPin), to keep from having root -load arbitrary kernel code via the module loader interface. - -This configuration is supported in **Linux 3.7 and greater** and thus should -only be enabled for such versions. - - - -Domain | `Config` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` - - - -It is also possible to block the loading of modules after startup with -"kernel.modules_disabled". - - - -Domain | `Variable` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` - - - --------------------------------------------------------------------------------- - - - -## 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. - - - -Domain | Object | _State_ ------------------------- | ------------------- | ---------- -Kernel-General-Drivers-1 | `USB` | _Disabled_ -Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ -Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ - - - --------------------------------------------------------------------------------- - -## Position Independent Executables - - - -Domain | Improvement --------------------------------- | ----------------------------- -Kernel-General-IndependentExec-1 | Kernel or/and platform part ? - - - - - -Domain | `compiler` and `linker` options | _State_ --------------------------------- | ------------------------------- | -------- -Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ - - - -Produce a position independent executable on targets which supports it. - --------------------------------------------------------------------------------- - -## Prevent Overwrite Attacks - -`-z,relro` 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. - - - -Domain | `compiler` and `linker` options | _State_ ---------------------------------- | ------------------------------- | -------- -Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ -Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ - - - -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 - - - -Domain | Improvement -------------------------------- | --------------- -Kernel-General-LibraryLinking-1 | Keep this part? - - - -It is recommended that dynamic linking should generally not be allowed. This -will avoid the user from replacing a library with malicious library. - - - -Domain | Object | Recommendations -------------------------------- | --------------- | -------------------------------- -Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. - - - - - -Linking everything statically doesn't change anything wrt security as binaries -will live under same user:group as libraries and setuid executables ignore -`LD_PRELOAD/LD_LIBRARY_PATH`. It also increases RSS footprint and creates -problems with upgrading. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.2_Memory.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.2_Memory.md deleted file mode 100644 index 57cd9a3..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.2_Memory.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: Memory ---- - -# Memory - -## Restrict access to kernel memory - -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: - - - -Domain | `Config` name | `Value` ------------------------------- | ---------------- | ------- -Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` - - - -In case applications in userspace need /dev/kmem support, it should be available -only for authenticated applications. - --------------------------------------------------------------------------------- - -## 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. - - - -Domain | `Config` name | `Value` ------------------------- | ------------------- | ------- -Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `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. - - - -Domain | `Config` name | `Value` --------------------- | ------------- | ------- -Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` - - - - - -- Enabling swap at runtime require `CAP_SYS_ADMIN`. -- Swap block device is usually under root:disk. -- Linux never swaps kernel pages. -- If swap disabling is not possible, swap encryption should be enabled. - - - --------------------------------------------------------------------------------- - - - -## 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 the exploits of kernel space. - -Both `KALLSYMS_ALL` and `KALLSYMS` shall be disabled; - - - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` -Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` - - - --------------------------------------------------------------------------------- - -## Stack protection - -To prevent stack-smashing, 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**. - - - -Domain | `Config` name | `Value` ---------------------- | -------------------------- | ------- -Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` - - - -Other defenses include things like shadow stacks. - --------------------------------------------------------------------------------- - -## 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. - - - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Memory-Access-1 | `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. - - - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` - - - --------------------------------------------------------------------------------- - -## Stack Smashing Attacks - - - -Domain | `compiler` and `linker` options | _State_ ------------------------------ | ------------------------------- | -------- -Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ - - - -Emit extra code to check for buffer overflows, such as stack smashing attacks. - --------------------------------------------------------------------------------- - -## Detect Buffer Overflows - - - -Domain | `compiler` options and `config` name | `Value` -------------------------------- | ------------------------------------ | ------- -Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` -Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` - - - -Helps detect some buffer overflow errors. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.3_Consoles.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.3_Consoles.md deleted file mode 100644 index 297950d..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.3_Consoles.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Consoles ---- - -# Serial - -## Disable serial console - -The serial console should be disabled to prevent an attacker from accessing this -powerful interface. - - - -Domain | `Config` name | `Value` ------------------------- | ---------------------------- | ------- -Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` -Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` -Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` -Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` - - - --------------------------------------------------------------------------------- - -## 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 commands 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. - - - -Domain | `Config` name | `Value` ------------------------------ | ------------------------- | ----------------------------------- -Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` -Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` -Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` - - - -It is recommended that any per-device settings (e.g: 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 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. - - - -Domain | `Config` name | `Value` ----------------------- | ------------- | ------- -Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `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. - - - -Domain | `Config` name | `Value` ------------------------ | -------------------- | ------- -Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `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. - - - -Domain | `Config` name | `Value` ------------------------------- | -------------------- | ------- -Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.4_Debug.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.4_Debug.md deleted file mode 100644 index e34839f..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.4_Debug.md +++ /dev/null @@ -1,251 +0,0 @@ ---- -title: Debug ---- - -# Debug - -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), the -`LLDB` next generation debugger or the `TCF` (Target Communications Framework) -agnostic framework. 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. - -## Kernel debug symbols - -Debug symbols should always be removed from production kernels as they provide a -lot of information to attackers. - - - -Domain | `Config` name | `Value` ----------------------- | ------------------- | ------- -Kernel-Debug-Symbols-1 | `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. - - - -At least `CONFIG_DEBUG_INFO_REDUCED` should be always enabled for developers to -convert addresses in oops messages to line numbers. - - - --------------------------------------------------------------------------------- - -## 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. - - - -Domain | `Config` name | `Value` ----------------------- | ---------------- | ------- -Kernel-Debug-Kprobes-1 | `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. - - - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Debug-Tracing-1 | `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. - - - -Domain | `Config` name | `Value` ------------------------- | ------------------ | ------- -Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` -Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `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. - - - -Domain | `Config` name | `Value` ------------------------- | ------------------------- | ------- -Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `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. - - - -Domain | `Config` name | `Value` ------------------- | --------------------- | ------- -Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` -Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `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. - - - -Domain | `Config` name | `Value` -------------------------- | ----------------- | ------- -Kernel-Debug-FileSystem-1 | `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. - - - -Domain | `Config` name | `Value` ------------------- | ------------- | ------- -Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` - - - --------------------------------------------------------------------------------- - -## Disable core dumps - -Core dumps provide a lot of debug information for hackers. So disabling core -dumps are recommended in production builds. - -This configuration is supported in **Linux 3.7 and greater** and thus should -only be disabled for such versions. - - - -Domain | `Config` name | `Value` ------------------------- | ----------------- | ------- -Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` - - - --------------------------------------------------------------------------------- - - - -## 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. - - - -Domain | `File` name | `Value` ----------------------------- | -------------------------------- | ------- -Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` - - - -Additionally, various files and directories should be readable only by the root -user: `/boot/vmlinuz*`, `/boot/System.map*`, `/sys/kernel/debug/`, -`/proc/slabinfo` - - - -Domain | `File` or `Directorie` name | _State_ ----------------------------- | --------------------------- | ----------------------------- -Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ -Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ - - - --------------------------------------------------------------------------------- - -## DMESG Restrictions - -When attackers try to develop "run anywhere" exploits for vulnerabilities, 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. - - - -Domain | `File` name | `Value` --------------------- | --------------------------------- | ------- -Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` - - - -Enable the below compiler and linker options when building user-space -applications to avoid stack smashing, buffer overflow attacks. - --------------------------------------------------------------------------------- - - - -## 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. - - - -Domain | `Config` name | `Value` ---------------------- | ----------------- | ------- -Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.5_FileSystems.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.5_FileSystems.md deleted file mode 100644 index 14f8c53..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.5_FileSystems.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: File Systems ---- - -# File System - -## 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. - -### Disable NFS file system - -NFS FileSystems are useful during development phases, but this can be a very -helpful way for an attacker to get files when you are in production mode, so we -must disable them. - - - -Domain | `Config` name | `Value` ------------------------- | --------------- | ------- -Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` -Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` - - - --------------------------------------------------------------------------------- - - - -## 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: - - - -Domain | `Partition` | `Value` --------------------------- | ------------------- | ----------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. -Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. -Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. - - - -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. - - - -Domain | `Config` name | _State_ or `Value` --------------------------- | ----------------------- | ----------------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md deleted file mode 100644 index 4074b6f..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Introduction ---- - -# Part 5 - Platform - -## Abstract - -The Automotive Grade Linux platform is a Linux distribution with **AGL** -compliant applications and services. The platform includes the following -software: - -- Linux **BSP** configured for reference boards. -- Proprietary device drivers for common peripherals on reference boards. -- Application framework. -- Windows/layer management (graphics). -- Sound resource management. -- An atomic software update system (chapter Update). -- Building and debug tools (based on Yocto project). - - - -Domain | Improvement -------------------- | -------------------------------- -Platform-Abstract-1 | Create a graphics and sound part. - - - -This part focuses on the AGL platform including all tools and techniques used to -upgrade the security and downgrade the danger. It must be possible to apply the -two fundamental principles written at the very beginning of the document. First -of all, security management must remain simple. You must also prohibit -everything by default, and then define a set of authorization rules. As cases to -deal with, we must: - -- Implement a **MAC** for processes and files. -- Limit communication between applications (_SystemBus_ and _SystemD_ part). -- Prohibit all tools used during development mode (_Utilities_ and _Services_ - part). -- Manage user capabilities (_Users_ part). -- Manage application permissions and policies (_AGLFw_ part). - - - -The tools and concepts used to meet these needs are only examples. Any other -tool that meets the need can be used. - - - -In AGL, as in many other embedded systems, different security mechanisms settle -in the core layers to ensure isolation and data privacy. While the Mandatory -Access Control layer (**SMACK**) provides global security and isolation, other -mechanisms like **Cynara** are required to check application's permissions at -runtime. Applicative permissions (also called "_privileges_") may vary depending -on the user and the application being run: an application should have access to -a given service only if it is run by the proper user and if the appropriate -permissions are granted. - -## Discretionary Access Control - -**D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux -method of separating users and groups from one another. In a shared environment -where multiple users have access to a computer or network, Unix IDs have offered -a way to contain access within privilege areas for individuals, or shared among -the group or system. The Android system took this one step further, assigning -new user IDs for each App. This was never the original intention of Linux UIDs, -but was able to provide Android’s initial security element: the ability to -sandbox applications. - -Although AGL mentions use of **DAC** for security isolation, the weight of the -security responsibility lies in the **M**andatory **A**ccess **C**ontrol -(**MAC**) and **Cynara**. Furthermore, there are system services with unique -UIDs. however,the system does not go to the extreme of Android, where every -application has its own UID. All sandboxing (app isolation) in AGL is handled in -the **MAC** contexts. - -## Mandatory Access Control - -**M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**, -whereby extended attributes (xattr) are associated with the filesystem. In the -case of AGL, the smackfs filesystem allows files and directories to be -associated with a SMACK label, providing the ability of further discrimination -on access control. A SMACK label is a simple null terminated character string -with a maximum of 255 bytes. While it doesn’t offer the richness of an SELinux -label, which provides a user, role,type, and level, the simplicity of a single -value makes the overall design far less complex. There is arguably less chance -of the security author making mistakes in the policies set forth. - --------------------------------------------------------------------------------- - - - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | -------------------------------------------------------------- -_ACL_ | **A**ccess **C**ontrol **L**ists -_alsa_ | **A**dvanced **L**inux **S**ound **A**rchitecture -_API_ | **A**pplication **P**rogramming **I**nterface -_AppFw_ | **App**lication **F**rame**w**ork -_BSP_ | **B**oard **S**upport **P**ackage -_Cap_ | **Cap**abilities -_DAC_ | **D**iscretionary **A**ccess **C**ontrol -_DDOS_ | **D**istributed **D**enial **O**f **S**ervice -_DOS_ | **D**enial **O**f **S**ervice -_IPC_ | **I**nter-**P**rocess **C**ommunication -_MAC_ | **M**andatory **A**ccess **C**ontrol -_PAM_ | **P**luggable **A**uthentication **M**odules -_SMACK_ | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.1_Mandatory_Access_Control.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.1_Mandatory_Access_Control.md deleted file mode 100644 index a8226dd..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.1_Mandatory_Access_Control.md +++ /dev/null @@ -1,176 +0,0 @@ ---- -title: Mandatory Access Control ---- - -# Mandatory Access Control - - - -We decided to put the **MAC** protection on the platform part despite the fact -that it applies to the kernel too, since its use will be mainly at the platform -level (except floor part). - - - -**M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the -Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL -uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol -**K**ernel (**SMACK**). This protection involves the creation of **SMACK** -labels as part of the extended attributes **SMACK** labels to the file extended -attributes. And a policy is also created to define the behaviour of each label. - -The kernel access controls is based on these labels and this policy. If there is -no rule, no access will be granted and as a consequence, what is not explicitly -authorized is forbidden. - -There are two types of **SMACK** labels: - -- **Execution SMACK** (Attached to the process): Defines how files are - _accessed_ and _created_ by that process. -- **File Access SMACK** (Written to the extended attribute of the file): Defines - _which_ process can access the file. - -By default a process executes with its File Access **SMACK** label unless an -Execution **SMACK** label is defined. - -AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System -into the following domains: - -- Floor. -- System. -- Applications, Services and User. - -See [AGL security framework -review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) -and [Smack White -Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf) -for more information. - --------------------------------------------------------------------------------- - - - -## Floor - -The _floor_ domain includes the base system services and any associated data and -libraries. This data remains unchanged at runtime. Writing to floor files or -directories is allowed only in development mode or during software installation -or upgrade. - -The following table details the _floor_ domain: - -Label | Name | Execution **SMACK** | File Access **SMACK** ------ | ----- | ------------------- | --------------------------------------- -`-` | Floor | `r-x` for all | Only kernel and internal kernel thread. -`^` | Hat | `---` for all | `rx` on all domains. -`*` | Star | `rwx` for all | None - - - -- The Hat label is Only for privileged system services (currently only - systemd-journal). Useful for backup or virus scans. No file with this label - should exist except in the debug log. - -- The Star label is used for device files or `/tmp` Access restriction managed - via **DAC**. Individual files remain protected by their **SMACK** label. - - - -Domain | `Label` name | Recommendations ------------------- | ------------ | ----------------------------------------------------------- -Kernel-MAC-Floor-1 | `^` | Only for privileged system services. -Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. - - - --------------------------------------------------------------------------------- - - - -## System - -The _system_ domain includes a reduced set of core system services of the OS and -any associated data. This data may change at runtime. - -The following table details the _system_ domain: - -Label | Name | Execution **SMACK** | File Access **SMACK** ----------------- | --------- | ----------------------------------------------- | --------------------- -`System` | System | None | Privileged processes -`System::Run` | Run | `rwxatl` for User and System label | None -`System::Shared` | Shared | `rwxatl` for system domain `r-x` for User label | None -`System::Log` | Log | `rwa` for System label `xa` for user label | None -`System::Sub` | SubSystem | Subsystem Config files | SubSystem only - - - -Domain | `Label` name | Recommendations -------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. -Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. -Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. -Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. -Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. - - - --------------------------------------------------------------------------------- - - - -## Applications, Services and User - -The _application_, _services_ and _user_ domain includes code that provides -services to the system and user, as well as any associated data. All code -running on this domain is under _Cynara_ control. - -The following table details the _application_, _services_ and _user_ domain: - -Label | Name | Execution **SMACK** | File Access **SMACK** -------------------- | ------ | --------------------------------------------------------------------------- | --------------------------- -`User::Pkg::$AppID` | AppID | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App -`User::Home` | Home | `rwx-t` from System label `r-x-l` from App | None -`User::App-Shared` | Shared | `rwxat` from System and User domains label of $User | None - - - -Domain | `Label` name | Recommendations -------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- -Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. -Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. -Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. - - - -## Attack Vectors - -There are 4 major components to the system: - -- The LSM kernel module. -- The `smackfs` filesystem. -- Basic utilities for policy management and checking. -- The policy/configuration data. - -As with any mandatory access system, the policy management needs to be carefully -separated from the checking, as the management utilities can become a convenient -point of attack. Dynamic additions to the policy system need to be carefully -verified, as the ability to update the policies is often needed, but introduces -a possible threat. Finally, even if the policy management is well secured, the -policy checking and failure response to that checking is also of vital -importance to the smooth operation of the system. - -While **MAC** is a certainly a step up in security when compared to DAC, there -are still many ways to compromise a SMACK-enabled Linux system. Some of these -ways are as follows: - -- Disabling SMACK at invocation of the kernel (with command-line: - security=none). -- Disabling SMACK in the kernel build and redeploying the kernel. -- Changing a SMACK attribute of a file or directory at install time. -- Tampering with a process with the CAP_MAC_ADMIN privilege. -- Setting/Re-setting the SMACK label of a file. -- Tampering with the default domains (i.e. - /etc/smack/accesses.d/default-access-domains). -- Disabling or tampering with the SMACK filesystem (i.e. /smackfs). -- Adding policies with `smackload` (adding the utility if not present). -- Changing labels with `chsmack` (adding the utility if not present). diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.2_SystemD.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.2_SystemD.md deleted file mode 100644 index 0ccd4e4..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.2_SystemD.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: SystemD ---- - -# SystemD - -`afm-system-daemon` is used to: - -- Manage users and user sessions. -- Setup applications and services (_CGroups_, _namespaces_, autostart, permissions). -- Use of `libsystemd` for its programs (event management, **D-Bus** interface). - - - -Domain | Object | Recommendations ------------------- | -------------- | ------------------------------------ -Platform-SystemD-1 | Security model | Use Namespaces for containerization. -Platform-SystemD-2 | Security model | Use CGroups to organise processes. - - - -See [systemd integration and user management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for more information. - -## Benefits - -- Removal of one privileged process: **afm-user-daemon** -- Access and use of high level features: - - - Socket activation. - - Management of users and integration of **PAM**. - - Dependency resolution to services. - - `Cgroups` and resource control. - - `Namespaces` containerization. - - Autostart of required API. - - Permissions and security settings. - - Network management. - - - -## CGroups - -Control Groups offer a lot of features, with the most useful ones you can -control: Memory usage, how much CPU time is allocated, how much device I/O is -allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise -processes (each service is a _CGroups_, and all processes started by that -service use that _CGroups_). By default, **SystemD** automatically creates a -hierarchy of slice, scope and service units to provide a unified structure for -the _CGroups_ tree. With the `systemctl` command, you can further modify this -structure by creating custom slices. Currently, in AGL, there are 2 slices -(**user.slice** and **system.slice**). - -## Namespaces - -### User side - -There are several ways of authenticating users (Key Radio Frequency, Phone, -Gesture, ...). Each authentication provides dynamic allocation of **uids** to -authenticated users. **Uids** is used to ensure privacy of users and **SMACK** -for applications privacy. - -First, the user initiates authentication with **PAM** activation. **PAM** -Standard offers highly configurable authentication with modular design like -face recognition, Voice identification or with a password. Then users should -access identity services with services and applications. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.3_SystemBus.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.3_SystemBus.md deleted file mode 100644 index 71a2212..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.3_SystemBus.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: SystemBus ---- - -# D-Bus - -D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and -daemon) that helps applications to talk to each other. The use of D-Bus is great -because it allows to implement discovery and signaling. - -The D-Bus session is by default addressed by environment variable -`DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable -`DBUS_SESSION_BUS_ADDRESS` is automatically set for user sessions. D-Bus usage -is linked to permissions. - -D-Bus has already had several [security -issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) -(mostly **DoS** issues), to allow applications to keep talking to each other. It -is important to protect against this type of attack to keep the system more -stable. - - - - -Domain | Object | Recommendations ---------------- | -------------- | ------------------------------------ -Platform-DBus-1 | Security model | Use D-Bus as IPC. -Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.4_Services.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.4_Services.md deleted file mode 100644 index c3aec00..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.4_Services.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: System services and daemons ---- - -# System services and daemons - - - -Domain | Improvement -------------------- | ----------- -Platform-Services-1 | SystemD ? -Platform-Services-2 | Secure daemon ? - - - -## Tools - -- **connman**: An internet connection manager designed to be slim and to use as - few resources as possible. It is a fully modular system that can be extended, - through plug-ins, to support all kinds of wired or wireless technologies. -- **bluez** is a Bluetooth stack. Its goal is to program an implementation of - the Bluetooth wireless standards specifications. In addition to the basic - stack, the `bluez-utils` and `bluez-firmware` packages contain low level - utilities such as `dfutool` which can interrogate the Bluetooth adapter - chipset in order to determine whether its firmware can be upgraded. -- **gstreamer** is a pipeline-based multimedia framework. It can be used to - build a system that reads files in one format, processes them, and exports - them in another format. -- **alsa** is a software framework and part of the Linux kernel that provides an - **API** for sound card device drivers. - - - -Domain | `Tool` name | _State_ --------------------- | ----------- | ------- -Platform-Utilities-1 | `connman` | _Used_ as a connection manager. -Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. -Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. -Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md deleted file mode 100644 index 3ce894d..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.5_Application_framework.md +++ /dev/null @@ -1,357 +0,0 @@ ---- -title: Application Framework ---- - -# Application framework/model (**AppFw**) - -The AGL application framework consists of several inter-working parts: - -- **SMACK**: The kernel level **LSM** (**L**inux **S**ecurity **M**odule) that - performs extended access control of the system. -- **Cynara**: the native gatekeeper daemon used for policy handling, updating to - the database and policy checking. -- Security Manager: a master service, through which all security events are - intended to take place. -- Several native application framework utilities: `afm-main-binding`, - `afm-user-daemon`, `afm-system-daemon`. - -The application framework manages: - -- The applications and services management: Installing, Uninstalling, Listing, - ... -- The life cycle of applications: Start -> (Pause, Resume) -> Stop. -- Events and signals propagation. -- Privileges granting and checking. -- API for interaction with applications. - - - -- The **security model** refers to the security model used to ensure security - and to the tools that are provided for implementing that model. It's an - implementation detail that should not impact the layers above the application - framework. - -- The **security model** refers to how **DAC** (**D**iscretionary **A**ccess - **C**ontrol), **MAC** (Mandatory Access Control) and `Capabilities` are used - by the system to ensure security and privacy. It also includes features of - reporting using audit features and by managing logs and alerts. - - - -The **AppFw** uses the security model to ensure the security and the privacy of -the applications that it manages. It must be compliant with the underlying -security model. But it should hide it to the applications. - - - -Domain | Object | Recommendations ----------------------- | -------------- | -------------------------------- -Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. - - - -See [AGL AppFw Privileges -Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) -and [AGL - Application Framework -Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) -for more information. - - - -The Security Manager communicates policy information to **Cynara**, which -retains information in its own database in the format of a text file with -comma-separated values (CSV). There are provisions to retain a copy of the CSV -text file when the file is being updated. - -Runtime checking occurs through **Cynara**. Each application that is added to -the framework has its own instantiation of a SMACK context and D-bus bindings. -The afb_daemon and Binder form a web-service that is communicated to through -http or a websocket from the application-proper. This http or websocket -interface uses a standard unique web token for API communication. - -![Application Framework Flow](App-flow.png) - -## Cynara - -There's a need for another mechanism responsible for checking applicative -permissions: Currently in AGL, this task depends on a policy-checker service -(**Cynara**). - -- Stores complex policies in databases. -- "Soft" security (access is checked by the framework). - -Cynara interact with **D-Bus** in order to deliver this information. - -Cynara consists of several parts: - -- Cynara: a daemon for controlling policies and responding to access control - requests. -- Database: a spot to hold policies. -- Libraries: several static and dynamic libraries for communicating with Cynara. - -The daemon communicates to the libraries over Unix domain sockets. The database -storage format is a series of CSV-like files with an index file. - -There are several ways that an attacker can manipulate policies of the Cynara -system: - -- Disable Cynara by killing the process. -- Tamper with the Cynara binary on-disk or in-memory. -- Corrupt the database controlled by Cynara. -- Tamper with the database controlled by Cynara. -- Highjack the communication between Cynara and the database. - -The text-based database is the weakest part of the system and although there are -some consistency mechanisms in place (i.e. the backup guard), these mechanisms -are weak at best and can be countered by an attacker very easily. - - - -Domain | Object | Recommendations ------------------------ | ----------- | ------------------------------------- -Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. - - - -### Policies - -- Policy rules: - - - Are simple - for pair [application context, privilege] there is straight - answer (single Policy Type): [ALLOW / DENY / ...]. - - No code is executed (no script). - - Can be easily cached and managed. - -- Application context (describes id of the user and the application credentials) - It is build of: - - - UID of the user that runs the application. - - **SMACK** label of application. - -## Holding policies - -Policies are kept in buckets. Buckets are set of policies which have additional -a property of default answer, the default answer is yielded if no policy matches -searched key. Buckets have names which might be used in policies (for -directions). - -## Attack Vectors - -The following attack vectors are not completely independent. While attackers may -have varying levels of access to an AGL system, experience has shown that a -typical attack can start with direct access to a system, find the -vulnerabilities, then proceed to automate the attack such that it can be invoked -from less accessible standpoint (e.g. remotely). Therefore, it is important to -assess all threat levels, and protect the system appropriately understanding -that direct access attacks are the door-way into remote attacks. - -### Remote Attacks - -The local web server interface used for applications is the first point of -attack, as web service APIs are well understood and easily intercepted. The -local web server could potentially be exploited by redirecting web requests -through the local service and exploiting the APIs. While there is the use of a -security token on the web service API, this is weak textual matching at best. -This will not be difficult to spoof. It is well known that [API Keys do not -provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/). - -It is likely that the architectural inclusion of an http / web-service interface -provided the most flexibility for applications to be written natively or in -HTML5. However, this flexibility may trade-off with security concerns. For -example, if a native application were linked directly to the underlying -framework services, there would be fewer concerns over remote attacks coming -through the web-service interface. - -Leaving the interface as designed, mitigations to attacks could include further -securing the interface layer with cryptographic protocols: e.g. encrypted -information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman). - -### User-level Native Attacks - -- Modifying the CSV data-base -- Modifying the SQLite DB -- Tampering with the user-level binaries -- Tampering with the user daemons -- Spoofing the D-bus Interface -- Adding executables/libraries - -With direct access to the device, there are many security concerns on the native -level. For example, as **Cynara** uses a text file data-base with -comma-separated values (CSV), an attacker could simply modify the data-base to -escalate privileges of an application. Once a single application has all the -privileges possible on the system, exploits can come through in this manner. -Similarly the SQLite database used by the Security Manager is not much different -than a simple text file. There are many tools available to add, remove, modify -entries in an SQLite data-base. - -On the next level, a common point of attack is to modify binaries or daemons for -exploiting functionality. There are many Linux tools available to aid in this -regard, including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml), -and [radare2](https://rada.re/r/). With the ability to modify binaries, an -attacker can do any number of activities including: removing calls to security -checks, redirecting control to bypass verification functionality, ignoring -security policy handling, escalating privileges, etc. - -Additionally, another attack vector would be to spoof the D-bus interface. D-bus -is a message passing system built upon Inter-Process Communication (IPC), where -structured messages are passed based upon a protocol. The interface is generic -and well documented. Therefore, modifying or adding binaries/libraries to spoof -this interface is a relatively straight-forward process. Once the interface has -been spoofed, the attacker can issue any number of commands that lead into -control of low-level functionality. - -Protecting a system from native attacks requires a methodical approach. First, -the system should reject processes that are not sanctioned to run. -Signature-level verification at installation time will help in this regard, but -run-time integrity verification is much better. Signatures need to originate -from authorized parties, which is discussed further in a later section on the -Application Store. - -On the next level, executables should not be allowed to do things where they -have not been granted permission. DAC and SMACK policies can help in this -regard. On the other hand, there remain concerns with memory accesses, system -calls, and other process activity that may go undetected. For this reason, a -secure environment which monitors all activity can give indication of all -unauthorized activity on the system. - -Finally, it is very difficult to catch attacks of direct tampering in a system. -These types of attacks require a defense-in-depth approach, where complementary -software protection and hardening techniques are needed. Tamper-resistance and -anti-reverse-engineering technologies include program -transformations/obfuscation, integrity verification, and white-box cryptography. -If applied in a mutually-dependent fashion and considering performance/security -tradeoffs, the approach can provide an effective barrier to direct attacks to -the system. Furthermore, the use of threat monitoring provides a valuable -telemetry/analytics capability and the ability to react and renew a system under -attack. - -### Root-level Native Attacks - -- Tampering the system daemon -- Tampering Cynara -- Tampering the security manager -- Disabling SMACK -- Tampering the kernel - -Once root-level access (i.e. su) has been achieved on the device, there are many -ways to compromise the system. The system daemon, **Cynara**, and the security -manager are vulnerable to tampering attacks. For example, an executable can be -modified in memory to jam a branch, jump to an address, or disregard a check. -This can be as simple as replacing a branch instruction with a NOP, changing a -memory value, or using a debugger (e.g. gdb, IDA) to change an instruction. -Tampering these executables would mean that policies can be ignored and -verification checks can be bypassed. - -Without going so far as to tamper an executable, the **SMACK** system is also -vulnerable to attack. For example, if the kernel is stopped and restarted with -the *security=none* flag, then SMACK is not enabled. Furthermore, `systemd` -starts the loading of **SMACK** rules during start-up. If this start-up process -is interfered with, then **SMACK** will not run. Alternatively, new policies can -be added with `smackload` allowing unforseen privileges to alternative -applications/executables. - -Another intrusion on the kernel level is to rebuild the kernel (as it is -open-source) and replace it with a copy that has **SMACK** disabled, or even -just the **SMACK** filesystem (`smackfs`) disabled. Without the extended label -attributes, the **SMACK** system is disabled. - -Root-level access to the device has ultimate power, where the entire system can -be compromised. More so, a system with this level access allows an attacker to -craft a simpler *point-attack* which can operate on a level requiring fewer -privileges (e.g. remote access, user-level access). - -## Vulnerable Resources - -### Resource: `afm-user-daemon` - -The `afm-user-daemon` is in charge of handling applications on behalf of a user. -Its main tasks are: - -- Enumerate applications that the end user can run and keep this list available - on demand. -- Start applications on behalf of the end user, set user running environment, - set user security context. -- List current runnable or running applications. -- Stop (aka pause), continue (aka resume), terminate a running instance of a - given application. -- Transfer requests for installation/uninstallation of applications to the - corresponding system daemon afm-system-daemon. - -The `afm-user-daemon` launches applications. It builds a secure environment for -the application before starting it within that environment. Different kinds of -applications can be launched, based on a configuration file that describes how -to launch an application of a given kind within a given launching mode: local or -remote. Launching an application locally means that the application and its -binder are launched together. Launching an application remotely translates in -only launching the application binder. - -The UI by itself has to be activated remotely by a request (i.e. HTML5 -homescreen in a browser). Once launched, running instances of the application -receive a `runid` that identifies them. `afm-user-daemon` manages the list of -applications that it has launched. When owning the right permissions, a client -can get the list of running instances and details about a specific running -instance. It can also terminate, stop or continue a given application. If the -client owns the right permissions, `afm-user-daemon` delegates the task of -installing and uninstalling applications to `afm-system-daemon`. - -`afm-user-daemon` is launched as a `systemd` service attached to a user session. -Normally, the service file is located at -/usr/lib/systemd/user/afm-user-daemon.service. - -Attacker goals: - -- Disable `afm-user-daemon`. -- Tamper with the `afm-user-daemon` configuration. - - /usr/lib/systemd/user/afm-user-daemon.service. - - Application(widget) config.xml file. - - /etc/afm/afm-launch.conf (launcher configuration). - -- Escalate user privileges to gain more access with `afm-user-daemon`. -- Install malicious application (widget). -- Tamper with `afm-user-daemon` on disk or in memory. - -### Resource: `afm-system-daemon` - -The `afm-system-daemon` is in charge of installing applications on the AGL -system. Its main tasks are: - -- Install applications and setup security framework for newly installed - applications. -- Uninstall applications. - -`afm-system-daemon` is launched as a `systemd` service attached to system. -Normally, the service file is located at -/lib/systemd/system/afm-systemdaemon.service. - -Attacker goals: - -- Disable `afm-system-daemon`. -- Tamper with the `afm-system-daemon` configuration. -- Tamper `afm-system-daemon` on disk or in memory. - -### Resource `afb-daemon` - -`afb-binder` is in charge of serving resources and features through an HTTP -interface. `afb-daemon` is in charge of binding one instance of an application -to the AGL framework and AGL system. The application and its companion binder -run in a secured and isolated environment set for them. Applications are -intended to access to AGL system through the binder. `afb-daemon` binders serve -files through HTTP protocol and offers developers the capability to expose -application API methods through HTTP or WebSocket protocol. - -Binder bindings are used to add APIs to `afb-daemon`. The user can write a -binding for `afb-daemon`. The binder `afb-daemon` serves multiple purposes: - -1. It acts as a gateway for the application to access the system. -2. It acts as an HTTP server for serving files to HTML5 applications. -3. It allows HTML5 applications to have native extensions subject to security - enforcement for accessing hardware resources or for speeding up parts of - algorithm. - -Attacker goals: - -- Break from isolation. -- Disable `afb-daemon`. -- Tamper `afb-demon` on disk or in memory. -- Tamper **capabilities** by creating/installing custom bindings for - `afb-daemon`. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.6_Utilities.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.6_Utilities.md deleted file mode 100644 index 6e69658..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.6_Utilities.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Utilities ---- - -# Utilities - -- **busybox**: Software that provides several stripped-down Unix tools in a - single executable file. Of course, it will be necessary to use a "production" - version of **busybox** in order to avoid all the tools useful only in - development mode. - - - -Domain | `Tool` name | _State_ --------------------- | ----------- | ---------------------------------------------------------------------- -Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. - - - -## Functionalities to exclude in production mode - -In production mode, a number of tools must be disabled to prevent an attacker -from finding logs for example. This is useful to limit the visible surface and -thus complicate the fault finding process. The tools used only in development -mode are marked by an '**agl-devel**' feature. When building in production mode, -these tools will not be compiled. - - - -Domain | `Utility` name and normal `path` | _State_ ---------------------- | ---------------------------------------------------- | ---------- -Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ -Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ -Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ -Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ -Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ -Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ -Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ -Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ -Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ -Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ -Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ -Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ -Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ -Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ -Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ -Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ -Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ -Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ -Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ -Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ -Platform-Utilities-22 | `SSH` | _Disabled_ -Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ -Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ -Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ -Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ -Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ -Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ -Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ -Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ -Platform-Utilities-31 | `awk` (busybox) | _Enabled_ -Platform-Utilities-32 | `cut` (busybox) | _Enabled_ -Platform-Utilities-33 | `df` (busybox) | _Enabled_ -Platform-Utilities-34 | `echo` (busybox) | _Enabled_ -Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ -Platform-Utilities-36 | `grep` (busybox) | _Enabled_ -Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ -Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ -Platform-Utilities-39 | `printf` (busybox) | _Enabled_ -Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ -Platform-Utilities-41 | `tail` (busybox) | _Enabled_ -Platform-Utilities-42 | `tee` (busybox) | _Enabled_ -Platform-Utilities-43 | `test` (busybox) | _Enabled_ - - - -The _Enabled_ Unix/Linux utilities above shall be permitted as they are often -used in the start-up scripts and for USB logging. If any of these utilities are -not required by the device then those should be removed. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md deleted file mode 100644 index c1a8506..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Users ---- - -# Users - -The user policy can group users by function within the car. For example, we can -consider a driver and his passengers. Each user is assigned to a single group to -simplify the management of space security. - -## Root Access - -The main applications, those that provide the principal functionality of the -embedded device, should not execute with root identity or any capability. - -If the main application is allowed to execute at any capability, then the entire -system is at the mercy of the said application's good behaviour. Problems arise -when an application is compromised and able to execute commands which could -consistently and persistently compromise the system by implanting rogue -applications. - -It is suggested that the middleware and the UI should run in a context on a user -with no capability and all persistent resources should be maintained without any -capability. - -One way to ensure this is by implementing a server-client paradigm. Services -provided by the system's drivers can be shared this way. The other advantage of -this approach is that multiple applications can share the same resources at the -same time. - - - -Domain | Object | Recommendations ---------------------- | ---------------- | ----------------------------------------------------- -Platform-Users-root-1 | Main application | Should not execute as root. -Platform-Users-root-2 | UI | Should run in a context on a user with no capability. - - - -Root access should not be allowed for the following utilities: - - - -Domain | `Utility` name | _State_ ---------------------- | -------------- | ------------- -Platform-Users-root-3 | `login` | _Not allowed_ -Platform-Users-root-4 | `su` | _Not allowed_ -Platform-Users-root-5 | `ssh` | _Not allowed_ -Platform-Users-root-6 | `scp` | _Not allowed_ -Platform-Users-root-7 | `sftp` | _Not allowed_ - - - -Root access should not be allowed for the console device. The development -environment should allow users to login with pre-created user accounts. - -Switching to elevated privileges shall be allowed in the development environment -via `sudo`. - --------------------------------------------------------------------------------- - - - -## Capabilities - - - -Domain | Improvement ------------------------------ | ------------------------ -Platform-Users-Capabilities-1 | Kernel or Platform-user? -Platform-Users-Capabilities-2 | Add config note. - - - -The goal is to restrict functionality that will not be useful in **AGL**. They -are integrated into the **LSM**. Each privileged transaction is associated with -a capability. These capabilities are divided into three groups: - -- e: Effective: This means the capability is “activated”. -- p: Permitted: This means the capability can be used/is allowed. -- i: Inherited: The capability is kept by child/subprocesses upon execve() for - example. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/App-flow.png b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/App-flow.png deleted file mode 100644 index 7b87c29..0000000 Binary files a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/App-flow.png and /dev/null differ diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md deleted file mode 100644 index 2925efb..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Introduction ---- - -# Part 6 - Application - -## Abstract - -**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. - -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 containment is achieved using the following protections: - -- Linux Native protection - - Mandatory Access Control (**MAC**) -- AGL Platform protections - - Origin Tracking and Validation - - Application Privilege Management and Enforcement via Cynara - - Authenticated Transport via D-Bus - -## 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 (**AppFw**) consists of a number of utilities and daemons -which provide context for the applications. Isolation is provided through -**SMACK** labels. - -## 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. - -![App Signing Flow](App_signing_flow.png) - -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. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | ---------------------------------------------------- -_3GPP_ | **3**rd **G**eneration **P**artnership **P**roject -_CASB_ | **C**loud **A**ccess **S**ecurity **B**roker -_DAST_ | **D**ynamic **A**pplication **S**ecurity **T**esting -_DPI_ | **D**eep **P**acket **I**nspection -_IDS_ | **I**ntrusion **D**etection **S**ystems -_IPS_ | **I**ntrusion **P**revention **S**ystems -_IPSec_ | **I**nternet **P**rotocol **Sec**urity -_LSM_ | **L**inux **S**ecurity **M**odule -_MITM_ | **M**an **I**n **T**he **M**iddle -_OSI_ | **O**pen **S**ystems **I**nterconnection -_SATS_ | **S**tatic **A**pplication **S**ecurity **T**esting diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.1_Installation.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.1_Installation.md deleted file mode 100644 index 9279be8..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.1_Installation.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Installation ---- - -# Local - - - -Domain | Improvement --------------------------- | ------------------------------ -Application-Installation-1 | Talk about AppFw offline mode. - - - -## Installation - -Applications can be delivered and installed with the base image using a special -offline-mode provided by the **AppFw**. Apps can also be installed at run time. - - - -During early release, default Apps are installed on the image at first boot. - - - - - -Domain | Object | Recommendations --------------------------- | --------- | ----------------------------------------------------------------------- -Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. -Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.2_Privilege_Management.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.2_Privilege_Management.md deleted file mode 100644 index 69445ac..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.2_Privilege_Management.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Privilege management ---- - -# Local - -## Privilege Management - -Application privileges are managed by **Cynara** and the security manager in the -**AppFw**. For more details, please refer to the **AppFw** documentation in -Platform part. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.3_Signature.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.3_Signature.md deleted file mode 100644 index 671de13..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.3_Signature.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Signature ---- - -# App Signature - - - -Domain | Improvement ------------------------ | ---------------------------------------------------------- -Application-Signature-1 | Add content (see secure build in Secure development part). - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.4_Services.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.4_Services.md deleted file mode 100644 index ccd809c..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.4_Services.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Services ---- - -# Services - - - -Domain | Improvement ----------------------- | ------------ -Application-Services-1 | Add content (Which services?). -Application-Services-2 | Add Binder. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/App_signing_flow.png b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/App_signing_flow.png deleted file mode 100644 index 56a7c23..0000000 Binary files a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/App_signing_flow.png and /dev/null differ diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.0_Abstract.md deleted file mode 100644 index 499d858..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.0_Abstract.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Introduction ---- - -# Part 7 - Connectivity - -## Abstract - -This part shows different Connectivity attacks on the car. - - - -Domain | Improvement ------------------------ | ----------------- -Connectivity-Abstract-1 | Improve abstract. - - - --------------------------------------------------------------------------------- - - - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | --------------------------------------------------------------------------------- -_ARP_ | **A**ddress **R**esolution **P**rotocol -_BLE_ | **B**luetooth **L**ow **E**nergy -_CAN_ | **C**ar **A**rea **N**etwork -_CCMP_ | **C**ounter-Mode/**C**BC-**M**ac **P**rotocol -_EDGE_ | **E**nhanced **D**ata **R**ates for **GSM** **E**volution - Evolution of **GPRS** -_GEA_ | **G**PRS **E**ncryption **A**lgorithm -_GPRS_ | **G**eneral **P**acket **R**adio **S**ervice (2,5G, 2G+) -_GSM_ | **G**lobal **S**ystem for **M**obile Communications (2G) -_HSPA_ | **H**igh **S**peed **P**acket **A**ccess (3G+) -_IMEI_ | **I**nternational **M**obile **E**quipment **I**dentity -_LIN_ | **L**ocal **I**nterconnect **N**etwork -_MOST_ | **M**edia **O**riented **S**ystem **T**ransport -_NFC_ | **N**ear **F**ield **C**ommunication -_OBD_ | **O**n-**B**oard **D**iagnostics -_PATS_ | **P**assive **A**nti-**T**heft **S**ystem -_PKE_ | **P**assive **K**eyless **E**ntry -_PSK_ | **P**hase-**S**hift **K**eying -_RDS_ | **R**adio **D**ata **S**ystem -_RFID_ | **R**adio **F**requency **I**dentification -_RKE_ | **R**emote **K**eyless **E**ntry -_SDR_ | **S**oftware **D**efined **R**adio -_SSP_ | **S**ecure **S**imple **P**airing -_TKIP_ | **T**emporal **K**ey **I**ntegrity **P**rotocol -_TPMS_ | **T**ire **P**ressure **M**onitoring **S**ystem -_UMTS_ | **U**niversal **M**obile **T**elecommunications **S**ystem (3G) -_USB_ | **U**niversal **S**erial **B**us -_WEP_ | **W**ired **E**quivalent **P**rivacy -_WPA_ | **W**ifi **P**rotected **A**ccess diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.1_Bus_And_Connectors.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.1_Bus_And_Connectors.md deleted file mode 100644 index c7b577a..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.1_Bus_And_Connectors.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Bus and connectors ---- - -# Bus - -We only speak about the **CAN** bus to take an example, because the different -attacks on bus like _FlewRay_, _ByteFlight_, _Most_ and _Lin_ use retro -engineering and the main argument to improve their security is to encrypt data -packets. We just describe them a bit: - -- **CAN**: Controller Area Network, developed in the early 1980s, is an - event-triggered controller network for serial communication with data rates up - to one MBit/s. **CAN** messages are classified over their respective - identifier. **CAN** controller broadcast their messages to all connected nodes - and all receiving nodes decide independently if they process the message. -- **FlewRay**: Is a deterministic and error-tolerant high-speed bus. With a data - rate up to 10 MBit/s. -- **ByteFlight**: Is used for safety-critical applications in motor vehicles - like air-bags. Byteflight runs at 10Mbps over 2 or 3 wires plastic optical - fibers. -- **Most**: Media Oriented System Transport, is used for transmitting audio, - video, voice, and control data via fiber optic cables. The speed is, for the - synchronous way, up to 24 MBit/s and asynchronous way up to 14 MBit/s. - **MOST** messages include always a clear sender and receiver address. -- **LIN**: Local Interconnect Network, is a single-wire subnet work for - low-cost, serial communication between smart sensors and actuators with - typical data rates up to 20 kBit/s. It is intended to be used from the year - 2001 on everywhere in a car, where the bandwidth and versatility of a **CAN** - network is not required. - -On just about every vehicle, **ECU**s (**E**lectronic **C**ontrol **U**nits) -communicate over a CAN 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. - - - -Domain | Tech name | Recommendations ----------------------------------- | --------- | -------------------------------------------------------------------------- -Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. - - - -See [Security in Automotive Bus -Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf) -for more information. - -# Connectors - -For the connectors, we supposed that they were disabled by default. For example, -the **USB** must be disabled to avoid attacks like BadUSB. If not, configure the -Kernel to only enable the minimum require **USB** devices. The connectors used -to diagnose the car like **OBD-II** must be disabled outside garages. - - - -Domain | Tech name | Recommendations ------------------------------------------ | --------- | ---------------------------------------------------------------------- -Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. -Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. -Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. -Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.2_Wireless.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.2_Wireless.md deleted file mode 100644 index ce0259e..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.2_Wireless.md +++ /dev/null @@ -1,261 +0,0 @@ ---- -title: Wireless ---- - -# Wireless - -In this part, we talk about possible remote attacks on a car, according to the -different areas of possible attacks. For each communication channels, we -describe attacks and how to prevent them with some recommendations. The main -recommendation is to always follow the latest updates of these remote -communication channels. - - - -Domain | Object | Recommendations ------------------------ | ------ | ------------------------------------------------------------------ -Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. - - - -We will see the following parts: - -- [Wifi](#wifi) - -- [Bluetooth](#bluetooth) - -- [Cellular](#cellular) - -- [Radio](#radio) - -- [NFC](#nfc) - - - -Domain | Improvement ------------------------ | ------------------------------------------- -Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). - - - --------------------------------------------------------------------------------- - -For existing automotive-specific means, we take examples of existing system -attacks from the _IOActive_ document ([A Survey of Remote Automotive Attack -Surfaces](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf)) -and from the ETH document ([Relay Attacks on Passive Keyless Entry and Start -Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf)). - -- [Telematics](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A40%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - -- [Passive Anti-Theft System - (PATS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A11%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C574%2C0%5D) - -- [Tire Pressure Monitoring System - (TPMS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A17%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - -- [Remote Keyless Entry/Start - (RKE)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A26%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - -- [Passive Keyless Entry (PKE)](https://eprint.iacr.org/2010/332.pdf) - --------------------------------------------------------------------------------- - - - -## Wifi - -### Attacks - -We can differentiate existing attacks on wifi in two categories: Those on -**WEP** and those on **WPA**. - -- **WEP** attacks: - - - **FMS**: (**F**luhrer, **M**antin and **S**hamir attack) is a "Stream cipher - attack on the widely used RC4 stream cipher. The attack allows an attacker - to recover the key in an RC4 encrypted stream from a large number of - messages in that stream." - - **KoreK**: "Allows the attacker to reduce the key space". - - **PTW**: (**P**yshkin **T**ews **W**einmann attack). - - **Chopchop**: Found by KoreK, "Weakness of the CRC32 checksum and the lack - of replay protection." - - **Fragmentation** - -- **WPA** attacks: - - - **Beck and Tews**: Exploit weakness in **TKIP**. "Allow the attacker to - decrypt **ARP** packets and to inject traffic into a network, even allowing - him to perform a **DoS** or an **ARP** poisoning". - - [KRACK](https://github.com/kristate/krackinfo): (K)ey (R)einstallation - (A)tta(ck) ([jira AGL - SPEC-1017](https://jira.automotivelinux.org/browse/SPEC-1017)). - -### Recommendations - -- Do not use **WEP**, **PSK** and **TKIP**. - -- Use **WPA2** with **CCMP**. - -- Should protect data sniffing. - - - -Domain | Tech name or object | Recommendations ----------------------------- | ------------------- | ------------------------------------------------------------------------- -Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled -Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used -Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. -Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. -Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. - - - -See [Wifi attacks WEP WPA](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf) and -[Breaking wep and wpa (Beck and -Tews)](https://dl.aircrack-ng.org/breakingwepandwpa.pdf) for more information. - --------------------------------------------------------------------------------- - - - -## Bluetooth - -### Attacks - -- **Bluesnarfing** attacks involve an attacker covertly gaining access to your - Bluetooth-enabled device for the purpose of retrieving information, including - addresses, calendar information or even the device's **I**nternational - **M**obile **E**quipment **I**dentity. With the **IMEI**, an attacker could - route your incoming calls to his cell phone. -- **Bluebugging** is a form of Bluetooth attack often caused by a lack of - awareness. Similar to bluesnarfing, bluebugging accesses and uses all phone - features but is limited by the transmitting power of class 2 Bluetooth radios, - normally capping its range at 10-15 meters. -- **Bluejacking** is the sending of unsolicited messages. -- **BLE**: **B**luetooth **L**ow **E**nergy - [attacks](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf). -- **DoS**: Drain a device's battery or temporarily paralyze the phone. - -### Recommendations - -- Not allowing Bluetooth pairing attempts without the driver's first manually - placing the vehicle in pairing mode. -- Monitoring. -- Use **BLE** with caution. -- For v2.1 and later devices using **S**ecure **S**imple **P**airing (**SSP**), - avoid using the "Just Works" association model. The device must verify that an - authenticated link key was generated during pairing. - - - -Domain | Tech name | Recommendations ---------------------------------- | ------------- | ------------------------------------------------------------ -Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. -Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring -Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. -Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. -Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. - - - -See [Low energy and the automotive -transformation](http://www.ti.com/lit/wp/sway008/sway008.pdf), [Gattacking -Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf), [Comprehensive -Experimental Analyses of Automotive Attack -Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf) and [With Low -Energy comes Low -Security](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf) -for more information. - --------------------------------------------------------------------------------- - - - -## Cellular - -### Attacks - -- **IMSI-Catcher**: Is a telephone eavesdropping device used for intercepting - mobile phone traffic and tracking location data of mobile phone users. - Essentially a "fake" mobile tower acting between the target mobile phone and - the service provider's real towers, it is considered a man-in-the-middle - (**MITM**) attack. - -- Lack of mutual authentication (**GPRS**/**EDGE**) and encryption with - **GEA0**. - -- **Fall back** from **UMTS**/**HSPA** to **GPRS**/**EDGE** (Jamming against - **UMTS**/**HSPA**). - -- 4G **DoS** attack. - -### Recommendations - -- Check antenna legitimacy. - - - -Domain | Tech name | Recommendations --------------------------------- | --------- | -------------------------- -Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid -Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. - - - -See [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data -communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf) -for more information. - --------------------------------------------------------------------------------- - -## Radio - -### Attacks - -- Interception of data with low cost material (**SDR** with hijacked DVB-T/DAB - for example). - -### Recommendations - -- Use the **R**adio **D**ata **S**ystem (**RDS**) only to send signals for audio - output and meta concerning radio. - - - -Domain | Tech name | Recommendations ------------------------------ | --------- | -------------------------------------------- -Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. - - - --------------------------------------------------------------------------------- - - - -## NFC - -### Attacks - -- **MITM**: Relay and replay attack. - -### Recommendations - -- Should implements protection against relay and replay attacks (Tokens, - etc...). -- Disable unneeded and unapproved services and profiles. -- NFC should be use encrypted link (secure channel). A standard key agreement - protocol like Diffie-Hellmann based on RSA or Elliptic Curves could be applied - to establish a shared secret between two devices. -- Automotive NFC device should be certified by NFC forum entity: The NFC Forum - Certification Mark shows that products meet global interoperability standards. -- NFC Modified Miller coding is preferred over NFC Manchester coding. - - - -Domain | Tech name | Recommendations ---------------------------- | --------- | ------------------------------------------------------ -Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. -Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.3_Cloud.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.3_Cloud.md deleted file mode 100644 index d4112fc..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/7_Connectivity/1.2.7.3_Cloud.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Cloud ---- - -# Cloud - -## Download - -- **authentication**: Authentication is the security process that validates the - claimed identity of a device, entity or person, relying on one or more - characteristics bound to that device, entity or person. - -- **Authorization**: Parses the network to allow access to some or all network - functionality by providing rules and allowing access or denying access based - on a subscriber's profile and services purchased. - - - -Domain | Object | Recommendations ----------------------------- | -------------- | -------------------------------------- -Application-Cloud-Download-1 | authentication | Must implement authentication process. -Application-Cloud-Download-2 | Authorization | Must implement Authorization process. - - - --------------------------------------------------------------------------------- - -## Infrastructure - -- **Deep Packet Inspection**: **DPI** provides techniques to analyze the payload - of each packet, adding an extra layer of security. **DPI** can detect and - neutralize attacks that would be missed by other security mechanisms. - -- A **DoS** protection in order to avoid that the Infrastructure is no more - accessible for a period of time. - -- **Scanning tools** such as **SATS** and **DAST** assessments perform - vulnerability scans on the source code and data flows on web applications. - Many of these scanning tools run different security tests that stress - applications under certain attack scenarios to discover security issues. - -- **IDS & IPS**: **IDS** detect and log inappropriate, incorrect, or anomalous - activity. **IDS** can be located in the telecommunications networks and/or - within the host server or computer. Telecommunications carriers build - intrusion detection capability in all network connections to routers and - servers, as well as offering it as a service to enterprise customers. Once - **IDS** systems have identified an attack, **IPS** ensures that malicious - packets are blocked before they cause any harm to backend systems and - networks. **IDS** typically functions via one or more of three systems: - - 1. Pattern matching. - 2. Anomaly detection. - 3. Protocol behavior. - - - - - -Domain | Object | Recommendations ----------------------------------- | ------------- | ---------------------------------------------------------- -Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. -Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. -Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. -Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). -Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. - - - --------------------------------------------------------------------------------- - -## Transport - -For data transport, it is necessary to **encrypt data end-to-end**. To prevent -**MITM** attacks, no third party should be able to interpret transported data. -Another aspect is the data anonymization in order to protect the leakage of -private information on the user or any other third party. - -The use of standards such as **IPSec** provides "_private and secure -communications over IP networks, through the use of cryptographic security -services, is a set of protocols using algorithms to transport secure data over -an IP network._". In addition, **IPSec** operates at the network layer of the -**OSI** model, contrary to previous standards that operate at the application -layer. This makes its application independent and means that users do not need -to configure each application to **IPSec** standards. - -**IPSec** provides the services below : - -- Confidentiality: A service that makes it impossible to interpret data if it is - not the recipient. It is the encryption function that provides this service by - transforming intelligible (unencrypted) data into unintelligible (encrypted) - data. -- Authentication: A service that ensures that a piece of data comes from where - it is supposed to come from. -- Integrity: A service that consists in ensuring that data has not been tampered - with accidentally or fraudulently. -- Replay Protection: A service that prevents attacks by re-sending a valid - intercepted packet to the network for the same authorization. This service is - provided by the presence of a sequence number. -- Key management: Mechanism for negotiating the length of encryption keys - between two **IPSec** elements and exchange of these keys. - -An additional means of protection would be to do the monitoring between users -and the cloud as a **CASB** will provide. - - - -Domain | Object | Recommendations ------------------------------ | ----------------------------------------- | --------------------------------- -Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.0_Abstract.md deleted file mode 100644 index cd47ed0..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.0_Abstract.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Introduction ---- - -# Part 8 - Update (**OTA**) - -## Abstract - -Updating applications and firmware is essential for the development of new -features and even more to fix security bugs. However, if a malicious third party -manages to alter the content during transport, it could alter the functioning of -the system and/or applications. The security of the updates is therefore a -critical point to evaluate in order to guarantee the integrity, the -confidentiality and the legitimacy of the transmitted data. - -## Attack Vectors - -Updates 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 back-end. -* 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) - -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. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | ------------------------------------------------------------------------- -_FOTA_ | **F**irmware **O**ver **T**he **A**ir -_MATE_ | **M**an **A**t **T**he **E**nd -_MITM_ | **M**an **I**n **T**he **M**iddle -_OTA_ | **O**ver **T**he **A**ir -_SOTA_ | **S**oftware **O**ver **T**he **A**ir -_TUF_ | **T**he **U**pdate **F**ramework diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.1_Firmware_Over_The_Air.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.1_Firmware_Over_The_Air.md deleted file mode 100644 index 34761e3..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.1_Firmware_Over_The_Air.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: FOTA ---- - -# Firmware Over The Air - -The firmware update is critical since its alteration back to compromise the -entire system. It is therefore necessary to take appropriate protective -measures. - -AGL includes the _meta-updater_ Yocto layer that enables OTA software updates -via [Uptane](https://uptane.github.io), an automotive-specific extension to [The -Update Framework](https://theupdateframework.github.io/). Uptane and TUF are -open standards that define a secure protocol for delivering and verifying -updates even when the servers and network--internet and car-internal--aren't -fully trusted. - -_meta-updater_ includes the application -[`aktualizr`](https://github.com/advancedtelematic/aktualizr), developed -Advanced Telematic Systems (now part of HERE Technologies) that enables OTA for -an ECU. `aktualizr` combined with Uptane is suitable for updating the firmware, -software, and other packages on even functionally critical ECUs. `aktualizr` can -be enabled with the free, open souce backend -[`ota-community-edition`](https://github.com/advancedtelematic/ota-community-edition). - -This FOTA update mechanism can be enabled through the `agl-sota` feature. - -## Building - -To build an AGL image that uses `aktualizr`, the following can be used. - -``` -source meta-agl/scripts/aglsetup.sh -m agl-sota -``` - -During the build, _meta-updater_ will use credentials downloaded from -`ota-community-edition` to sign metadata verifying the build as authentic. These -signatures are part of the Uptane framework and are used to verify FOTA updates. - -## Atomic Upgrades with Rollbacks - -`aktualizr`'s primary method of updating firmware is to use `libostree` with -binary diffs. The binary diffs use the least amout of bandwidth, and by it's -nature `libostree` stores current and previous firmware versions on disk or in -flash memory to allow for rollbacks. - -`libostree` is a content addressable object store much like `git`. Versions are -specified via SHA2-256. These hashes are signed in the Uptane metadata and are -robust against cryptographic compromise. diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.2_Software_Over_The_Air.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.2_Software_Over_The_Air.md deleted file mode 100644 index bd4142f..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.2_Software_Over_The_Air.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: SOTA ---- - -# Software Over The Air - -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 **OTA** update model, securing these processes becomes a high -priority. - -**SOTA** is made possible by **AppFw** (See Platform part). It will be possible -to manage in a simple way the packets (i.g. Android like). - - - -Domain | Improvement -------------- | ----------------- -Update-SOTA-1 | Part to complete. - - diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/9_Secure_development/1.2.9.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/9_Secure_development/1.2.9.0_Abstract.md deleted file mode 100644 index bfceefe..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/9_Secure_development/1.2.9.0_Abstract.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Introduction ---- - -# Part 9 - Secure development - -In order to save a lot of time in code auditing, developers must follow coding -guidelines. - -## Secure build - -### Kernel build - -Tools like: - -- [Code optimisation](https://github.com/jduck/lk-reducer). -- [Kernel Drivers test](https://github.com/ucsb-seclab/dr_checker) with - [docs](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pdf). - - - -Domain | Improvement ------------------------ | ------------ -SecureDev-SecureBuild-1 | Add content. - - - -## App/Widget signatures - - - -Domain | Improvement ----------------------- | ------------ -SecureDev-Signatures-1 | Add content. - - - -## Code audit - -These tools are used to check the correct implementation of functionalities and -compliance with related good practices. - -- [Continuous Code Quality](https://www.sonarqube.org/). - - - -Domain | Improvement ---------------------- | ----------------------------------------------------- -SecureDev-CodeAudit-1 | Add CVE analyser. -SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). - - - -### SATS - -- [RATS](https://github.com/andrew-d/rough-auditing-tool-for-security) (Maybe to - old). -- [Flaw Finder](https://www.dwheeler.com/flawfinder/). - -- [wiki - list](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis). - -- [Mathematical - approach](https://perso.univ-rennes1.fr/david.lubicz/planches/David_Pichardie.pdf). - -It is necessary to verify that the application code does not use functions that -are depreciated and recognized as unsecured or cause problems. - -### DATS - -- [wiki - list](https://en.wikipedia.org/wiki/Dynamic_program_analysis#Example_tools). diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md b/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md new file mode 100644 index 0000000..ee5e7f7 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md @@ -0,0 +1,250 @@ +--- +title: Overview +--- + +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. + +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. + +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. + +Security domains will allow us to create a set of tests verifying the security +of Automotive Grade Linux. + +This document is firstly based on an existing AGL security-blueprint. + +**For security to be effective, the concepts must be simple. And by default, +anything that is not allowed is forbidden.** + +We will cover topics starting from the lowest level (_Hardware_) up to the +highest levels (_Connectivity_ and _Application_). We will move quickly on +_Hardware_ and _Connectivity_ because this is not supported at our level. +Solutions of connectivity problems concern updates and secured settings while +hardware securing is related to the manufacturers. + +## Adversaries + +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 automotive 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. + +## 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) | + +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. + +## 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 +prioritization of the the assets in a concrete vehicle network can be achieved +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 | | | + +## Hardening term + +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 devices. 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. + +## AGL security overview + +AGL roots are based on security concepts. Those concepts are implemented by the +security framework as shown in this picture: + +![AGL architecture](images/WhiteBoxArchi.png) + +-------------------------------------------------------------------------------- + +# Acronyms and Abbreviations + +The following table lists the strongest terms utilized within all this document. + +| Acronyms or Abbreviations | Description | +|---------------------------|-------------------------------------| +| _AGL_ | **A**utomotive **G**rade **L**inux | +| _ECU_ | **E**lectronic **C**ontrol **U**nit | + +-------------------------------------------------------------------------------- + +# References + +- [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html). + - _http:// + docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html_ +- **[2017]** - [kernel + security](https://www.kernel.org/doc/Documentation/security/). + - _https:// www.kernel.org/doc/Documentation/security/_ +- **[2017]** - [Systemd integration and user + management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf). + - _http:// iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf_ +- **[2017]** - [AGL - Application Framework + Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf). + - _http:// iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf_ +- **[2017]** - [Improving Vehicle + Cybersecurity](https://access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf). + - _https:// + access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf_ +- **[2016]** - [AGL framework + overview](http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html). + - _http:// + docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html_ +- **[2016]** - + [SecureBoot-SecureSoftwareUpdates](http://iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf). + - _http:// + iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf_ +- **[2016]** - [Linux Automotive + Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf). + - _http:// + iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf_ +- **[2016]** - [Automotive Security Best + Practices](https://www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf). + - _https:// + www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf_ +- **[2016]** - [Gattacking Bluetooth Smart + Devices](http://gattack.io/whitepaper.pdf). + - _http:// gattack.io/whitepaper.pdf_ +- **[2015]** - [Comprehensive Experimental Analysis of Automotive Attack + Surfaces](http://www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf). + - _http:// + www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf_ +- **[2015]** - [Security in Automotive Bus + Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf). + - _http:// + citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf_ +- **[2014]** - [IOActive Remote Attack + Surface](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf). + - _https:// www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf_ +- **[2011]** - [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data + communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf). + - _https:// + media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf_ +- **[2011]** - [Comprehensive Experimental Analyses of Automotive Attack + Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf). + - _http:// www.autosec.org/pubs/cars-usenixsec2011.pdf_ +- **[2010]** - [Relay Attacks on Passive Keyless Entry and Start Systems in + Modern Cars](https://eprint.iacr.org/2010/332.pdf). + - _https:// eprint.iacr.org/2010/332.pdf_ +- **[2010]** - [Wifi attacks wep + wpa](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf). + - _https:// matthieu.io/dl/wifi-attacks-wep-wpa.pdf_ +- **[2008]** - + [SMACK](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf). + - _http:// + schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf_ diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md b/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md new file mode 100644 index 0000000..328dd15 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md @@ -0,0 +1,64 @@ +--- +title: Hardware +--- + +The Automotive Grade Linux 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. + +You will find in this first part everything that concerns the hardware security. +The goal is to protect system against all attacks that are trying to gain +additional privileges by recovering and/or changing cryptographic keys in order +to alter the integrity of the boot. We should also prevent hardware +modifications in order to achieve this goal. We will expose below some examples +of possible configurations. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | -------------------------------------- +_HSM_ | **H**ardware **S**ecurity **M**odule +_NVM_ | **N**on-**V**olatile **M**emory +_SHE_ | **S**ecure **H**ardware **E**xtensions + +-------------------------------------------------------------------------------- + +## Integrity + +The board must store hardcoded cryptographic keys in order to verify among +others the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and +**SHE** to enhance the security of their board. + +Domain | Object | Recommendations +-------------------- | ---------- | ---------------------------------- +Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. +Hardware-Integrity-2 | Board | Must use a HSM. +Hardware-Integrity-3 | RTC | Must not be alterable. + +-------------------------------------------------------------------------------- + +## Certificates + +Domain | Object | Recommendations +---------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. +Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. +Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. + +-------------------------------------------------------------------------------- + +## Memory + +Domain | Object | Recommendations +----------------- | ---------- | ------------------------------------------------------------------------------------ +Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. +Hardware-Memory-2 | Bootloader | Internal NVM only +Hardware-Module-3 | - | HSM must be used to secure keys. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md b/docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md new file mode 100644 index 0000000..cdaa84c --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md @@ -0,0 +1,261 @@ +--- +title: Secure Boot +--- + +Domain | Improvement +--------------- | ---------------------------------------------------- +Boot-Abstract-1 | More generic and add examples (The chain of trust). + +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. + +**Boot Hardening**: Steps/requirements to configure the boot sequence, in order +to restrict the device from executing anything other than the approved software +image. + +In this part, we will see a series of settings that will allow us to improve +security during boot phase. 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. If the integrity is not checked or if a critical error +occurs, the system must boot on a very stable backup image. + +**Requirements**: These requirements must be met even if an alternative version +of the Linux kernel is chosen. + +**Recommendations**: Detailed 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. + +Domain | Improvement +--------------- | ------------------------------------------- +Boot-Abstract-1 | Review the definition of the "boot loader". + +**Boot loader**: 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 the Kernel/system image integrity, then loads the +Kernel/system image before passing control to it. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | ----------------------------------------------------------------------- +_FUSE_ | **F**ilesystem in **U**ser**S**pac**E** +_OTP_ | **O**ne-**T**ime-**P**rogrammable +_DOCSIS_ | **D**ata **O**ver **C**able **S**ervice **I**nterface **S**pecification + +# Image + +## Image selection + +The boot process shall be uninterruptible 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_. + +Domain | _Variable_ / `Config` name | `Value` +---------------------- | -------------------------- | ------- +Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` +Boot-Image-Selection-2 | _bootdelay_ | `-2` + +-------------------------------------------------------------------------------- + +## Image authenticity + +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: + +```sh +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 verification. +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. + +Domain | `Config` name | _State_ +------------------------- | ---------------------------- | -------- +Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ +Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ +Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ +Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ +Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ +Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ + +# Communication modes + +## Disable USB, Serial and DOCSIS Support + +To disable USB support in U-Boot, following config's 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. +``` + +In addition, disable unnecessary communication modes like Ethernet, Serial +ports, DOCSIS in U-Boot and sboot that are not necessary. + +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. + +Domain | Communication modes | _State_ +-------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- +Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. +Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. +Boot-Communication-3 | `Ethernet` | _Disabled_ +Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ +Boot-Communication-5 | `Serial ports` | _Disabled_ + +Domain | `Config` name | _State_ +------------------------ | ----------------------- | ------------- +Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ +Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ +Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ +Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ +Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ + +-------------------------------------------------------------------------------- + +## Disable all unused Network Interfaces + +Only used network interfaces should be enabled. Where possible, services should +also be limited to those necessary. + +Domain | Communication modes | _State_ +-------------------- | -------------------- | --------------------------------------------------------------------------------------------- +Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. + +## Remove or Disable Unnecessary Services, Ports, and Devices + +Restrict the `services`, `ports` and `devices` to those used. + +Domain | Object | Recommendations +-------------------- | --------------------------------- | ------------------------------------------------------------- +Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. + +## Disable flash access + +**Recommendation**: + +In U-Boot following flash memory commands shall be disabled: + +**NAND**: Support for nand flash access available through `do_nand` has to be +disabled. + +Domain | `Command` name | _State_ +-------------------------- | -------------- | --------- +Boot-Communication-Flash-1 | `do_nand` | _Disable_ + +Similarly sboot should disable flash access support through command line if any. + +# Consoles + +## Disable serial console + +Serial console output shall be disabled. To disable console output in U-Boot, +set the following macros: + +Domain | `Config` name | `Value` +---------------------- | --------------------------------------- | --------- +Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` +Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` +Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` + +Domain | Improvement +--------------- | ------------------------------------ +Boot-Consoles-1 | Secure loader: No reference earlier? + +And set "**silent**" environment variable. For the Secure loader, disable the +traces by not defining the below macro: + +Domain | `Environment variable` name | _State_ +---------------------- | --------------------------- | ------------- +Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ + +For sboot proper configuration needs to be done to disable the serial console. + +-------------------------------------------------------------------------------- + +## 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 the 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: + +Domain | `Config` name | _State_ +-------------------------- | ---------------------------- | --------- +Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` +Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` +Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` +Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` +Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` +Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` +Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` +Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` +Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` +Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` +Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` +Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` + +-------------------------------------------------------------------------------- + +## (Recommendation) 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. +``` + +Domain | `Command` name | _State_ +----------------------- | -------------- | ---------- +Boot-Consoles-MemDump-1 | `md` | _Disabled_ +Boot-Consoles-MemDump-2 | `mm` | _Disabled_ +Boot-Consoles-MemDump-3 | `nm` | _Disabled_ +Boot-Consoles-MemDump-4 | `mw` | _Disabled_ +Boot-Consoles-MemDump-5 | `cp` | _Disabled_ +Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ +Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ +Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ +Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ + +Similarly, memory dump support shall be disabled from sboot. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md b/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md new file mode 100644 index 0000000..61cc227 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md @@ -0,0 +1,17 @@ +--- +title: Hypervisor +--- + +**Definition** : "A hypervisor or virtual machine monitor (VMM) is computer +software, firmware or hardware that creates and runs virtual machines". + +It must include a signature verification (possibly delegated). + +Domain | Improvement +--------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). + +## Native or Bare-metal hypervisors + +These hypervisors run directly on the host's hardware to control the hardware +and to manage guest operating systems. Those are the ones we're interested in. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md b/docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md new file mode 100644 index 0000000..33e24d5 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md @@ -0,0 +1,941 @@ +--- +title: Kernel +--- + +**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. + +At the Kernel level, we must ensure that no console can be launched. It could be +used to change the behavior of the system or to have more information about it. +Another aspect is the protection of the memory used by the Kernel. + +The next sub-sections contain information on various kernel configuration +options to enhance the security in the kernel (3.10.17) and also for +applications compiled to take advantage of these security features. +Additionally, there are also configuration options that protect from known +vulnerable configuration options. Here's a high level summary of various kernel +configurations that shall be required for deployment. + +## 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. 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. +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 verification 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 this +section. + +# General configuration + +## Mandatory Access Control + +Kernel should controls access with labels and policy. + +Domain | `Config` name | `Value` +-------------------- | -------------- | -------------------------------------- +Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m +Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m +Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y +Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y +Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y +Kernel-General-MAC-6 | CONFIG_SECURITY | y +Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y +Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y + +Please also refer to the [Mandatory Access Control documentation in +Platform](5_Platform.md). You can also find useful documentation and +links on wikipedia about +[**MAC**](https://en.wikipedia.org/wiki/Mandatory_access_control) and about +[**SMACK**](https://en.wikipedia.org/wiki/Simplified_Mandatory_Access_Control_Kernel). + +-------------------------------------------------------------------------------- + +## Disable kexec + +**Kexec** is a system call that enables you to load and boot into another kernel +from the currently running kernel. This feature is not required in a production +environment. + + + +Domain | `Config` name | `Value` +---------------------- | -------------- | ------- +Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` + + + + + +**kexec** can load arbitrary kernels but signing of new kernel can be enforced +like it is can be enforced for new modules. + +-------------------------------------------------------------------------------- + +## Disable kernel IP auto-configuration + +It is preferable to have an 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. + + + +Domain | `Config` name | `Value` +--------------------------- | --------------- | ------- +Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable Sysctl syscall support + +Enabling this will result in code being included that is hard to maintain and +not well tested. + + + +Domain | `Config` name | `Value` +------------------------------- | ----------------------- | ------- +Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable Legacy Linux Support + +There are some Kernel Configs which are present only to support legacy binaries. +See also "Consoles" part in order to 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. + + + +Domain | `Config` name | `Value` +---------------------------- | --------------- | ------- +Kernel-General-LegacyLinux-1 | `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, can 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 that is supported in +**Linux 3.9 and greater**. + + + +Domain | `Config` name | `Value` +--------------------------- | ------------------------------ | ------- +Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` + + + + + +It doesn't strictly need to be `setuid`, there is an option of shipping firmware +builtin into kernel without initrd/filesystem. + + + +-------------------------------------------------------------------------------- + +## 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. + + + +Domain | `Config` name | `Value` +---------------------------- | ---------------------- | ------- +Kernel-General-PanicOnOOPS-1 | `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. + + + +Domain | `Config` name | `Value` +-------------------------- | -------------------- | ------- +Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` +Kernel-General-SocketMon-2 | `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. + + + +Domain | `Config` name | `Value` +------------------------ | ---------------- | ------- +Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` + + + +-------------------------------------------------------------------------------- + +## Enable Enforced Module Signing + +The kernel should never allow an unprivileged user the ability to load specific +kernel modules, since that would provide a facility to unexpectedly extend the +available attack surface. + +To protect against even privileged users, systems may need to either disable +module loading entirely, or provide signed modules (e.g. +`CONFIG_MODULE_SIG_FORCE`, or dm-crypt with LoadPin), to keep from having root +load arbitrary kernel code via the module loader interface. + +This configuration is supported in **Linux 3.7 and greater** and thus should +only be enabled for such versions. + + + +Domain | `Config` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` + + + +It is also possible to block the loading of modules after startup with +"kernel.modules_disabled". + + + +Domain | `Variable` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` + + + +-------------------------------------------------------------------------------- + + + +## 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. + + + +Domain | Object | _State_ +------------------------ | ------------------- | ---------- +Kernel-General-Drivers-1 | `USB` | _Disabled_ +Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ +Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ + + + +-------------------------------------------------------------------------------- + +## Position Independent Executables + + + +Domain | Improvement +-------------------------------- | ----------------------------- +Kernel-General-IndependentExec-1 | Kernel or/and platform part ? + + + + + +Domain | `compiler` and `linker` options | _State_ +-------------------------------- | ------------------------------- | -------- +Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ + + + +Produce a position independent executable on targets which supports it. + +-------------------------------------------------------------------------------- + +## Prevent Overwrite Attacks + +`-z,relro` 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. + + + +Domain | `compiler` and `linker` options | _State_ +--------------------------------- | ------------------------------- | -------- +Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ +Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ + + + +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 + + + +Domain | Improvement +------------------------------- | --------------- +Kernel-General-LibraryLinking-1 | Keep this part? + + + +It is recommended that dynamic linking should generally not be allowed. This +will avoid the user from replacing a library with malicious library. + + + +Domain | Object | Recommendations +------------------------------- | --------------- | -------------------------------- +Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. + +Linking everything statically doesn't change anything wrt security as binaries +will live under same user:group as libraries and setuid executables ignore +`LD_PRELOAD/LD_LIBRARY_PATH`. It also increases RSS footprint and creates +problems with upgrading. + +# Memory + +## Restrict access to kernel memory + +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: + +Domain | `Config` name | `Value` +------------------------------ | ---------------- | ------- +Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` + +In case applications in userspace need /dev/kmem support, it should be available +only for authenticated applications. + +-------------------------------------------------------------------------------- + +## 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. + + + +Domain | `Config` name | `Value` +------------------------ | ------------------- | ------- +Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `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. + + + +Domain | `Config` name | `Value` +-------------------- | ------------- | ------- +Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` + + + + + +- Enabling swap at runtime require `CAP_SYS_ADMIN`. +- Swap block device is usually under root:disk. +- Linux never swaps kernel pages. +- If swap disabling is not possible, swap encryption should be enabled. + + + +-------------------------------------------------------------------------------- + + + +## 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 the exploits of kernel space. + +Both `KALLSYMS_ALL` and `KALLSYMS` shall be disabled; + + + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` +Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` + + + +-------------------------------------------------------------------------------- + +## Stack protection + +To prevent stack-smashing, 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**. + + + +Domain | `Config` name | `Value` +--------------------- | -------------------------- | ------- +Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` + + + +Other defenses include things like shadow stacks. + +-------------------------------------------------------------------------------- + +## 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. + + + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Memory-Access-1 | `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. + + + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` + + + +-------------------------------------------------------------------------------- + +## Stack Smashing Attacks + + + +Domain | `compiler` and `linker` options | _State_ +----------------------------- | ------------------------------- | -------- +Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ + + + +Emit extra code to check for buffer overflows, such as stack smashing attacks. + +-------------------------------------------------------------------------------- + +## Detect Buffer Overflows + +Domain | `compiler` options and `config` name | `Value` +------------------------------- | ------------------------------------ | ------- +Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` +Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` + +Helps detect some buffer overflow errors. + +# Serial + +## Disable serial console + +The serial console should be disabled to prevent an attacker from accessing this +powerful interface. + +Domain | `Config` name | `Value` +------------------------ | ---------------------------- | ------- +Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` +Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` +Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` +Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` + +-------------------------------------------------------------------------------- + +## 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 commands 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. + + + +Domain | `Config` name | `Value` +----------------------------- | ------------------------- | ----------------------------------- +Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` +Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` +Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` + + + +It is recommended that any per-device settings (e.g: 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 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. + + + +Domain | `Config` name | `Value` +---------------------- | ------------- | ------- +Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `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. + + + +Domain | `Config` name | `Value` +----------------------- | -------------------- | ------- +Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `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. + + + +Domain | `Config` name | `Value` +------------------------------ | -------------------- | ------- +Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` + +# Debug + +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), the +`LLDB` next generation debugger or the `TCF` (Target Communications Framework) +agnostic framework. 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. + +## Kernel debug symbols + +Debug symbols should always be removed from production kernels as they provide a +lot of information to attackers. + + + +Domain | `Config` name | `Value` +---------------------- | ------------------- | ------- +Kernel-Debug-Symbols-1 | `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. + + + +At least `CONFIG_DEBUG_INFO_REDUCED` should be always enabled for developers to +convert addresses in oops messages to line numbers. + + + +-------------------------------------------------------------------------------- + +## 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. + + + +Domain | `Config` name | `Value` +---------------------- | ---------------- | ------- +Kernel-Debug-Kprobes-1 | `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. + + + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Debug-Tracing-1 | `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. + + + +Domain | `Config` name | `Value` +------------------------ | ------------------ | ------- +Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` +Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `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. + + + +Domain | `Config` name | `Value` +------------------------ | ------------------------- | ------- +Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `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. + + + +Domain | `Config` name | `Value` +------------------ | --------------------- | ------- +Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` +Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `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. + + + +Domain | `Config` name | `Value` +------------------------- | ----------------- | ------- +Kernel-Debug-FileSystem-1 | `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. + + + +Domain | `Config` name | `Value` +------------------ | ------------- | ------- +Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` + + + +-------------------------------------------------------------------------------- + +## Disable core dumps + +Core dumps provide a lot of debug information for hackers. So disabling core +dumps are recommended in production builds. + +This configuration is supported in **Linux 3.7 and greater** and thus should +only be disabled for such versions. + + + +Domain | `Config` name | `Value` +------------------------ | ----------------- | ------- +Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` + + + +-------------------------------------------------------------------------------- + + + +## 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. + + + +Domain | `File` name | `Value` +---------------------------- | -------------------------------- | ------- +Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` + + + +Additionally, various files and directories should be readable only by the root +user: `/boot/vmlinuz*`, `/boot/System.map*`, `/sys/kernel/debug/`, +`/proc/slabinfo` + + + +Domain | `File` or `Directorie` name | _State_ +---------------------------- | --------------------------- | ----------------------------- +Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ + + + +-------------------------------------------------------------------------------- + +## DMESG Restrictions + +When attackers try to develop "run anywhere" exploits for vulnerabilities, 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. + + + +Domain | `File` name | `Value` +-------------------- | --------------------------------- | ------- +Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` + + + +Enable the below compiler and linker options when building user-space +applications to avoid stack smashing, buffer overflow attacks. + +-------------------------------------------------------------------------------- + + + +## 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. + + + +Domain | `Config` name | `Value` +--------------------- | ----------------- | ------- +Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` + +# File System + +## 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. + +### Disable NFS file system + +NFS FileSystems are useful during development phases, but this can be a very +helpful way for an attacker to get files when you are in production mode, so we +must disable them. + + + +Domain | `Config` name | `Value` +------------------------ | --------------- | ------- +Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` +Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` + + + +-------------------------------------------------------------------------------- + + + +## 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: + + + +Domain | `Partition` | `Value` +-------------------------- | ------------------- | ----------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. +Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. + + + +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. + + + +Domain | `Config` name | _State_ or `Value` +-------------------------- | ----------------------- | ----------------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md b/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md new file mode 100644 index 0000000..917404b --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md @@ -0,0 +1,921 @@ +--- +title: Platform +--- + +The Automotive Grade Linux platform is a Linux distribution with **AGL** +compliant applications and services. The platform includes the following +software: + +- Linux **BSP** configured for reference boards. +- Proprietary device drivers for common peripherals on reference boards. +- Application framework. +- Windows/layer management (graphics). +- Sound resource management. +- An atomic software update system (chapter Update). +- Building and debug tools (based on Yocto project). + + + +Domain | Improvement +------------------- | -------------------------------- +Platform-Abstract-1 | Create a graphics and sound part. + + + +This part focuses on the AGL platform including all tools and techniques used to +upgrade the security and downgrade the danger. It must be possible to apply the +two fundamental principles written at the very beginning of the document. First +of all, security management must remain simple. You must also prohibit +everything by default, and then define a set of authorization rules. As cases to +deal with, we must: + +- Implement a **MAC** for processes and files. +- Limit communication between applications (_SystemBus_ and _SystemD_ part). +- Prohibit all tools used during development mode (_Utilities_ and _Services_ + part). +- Manage user capabilities (_Users_ part). +- Manage application permissions and policies (_AGLFw_ part). + + + +The tools and concepts used to meet these needs are only examples. Any other +tool that meets the need can be used. + + + +In AGL, as in many other embedded systems, different security mechanisms settle +in the core layers to ensure isolation and data privacy. While the Mandatory +Access Control layer (**SMACK**) provides global security and isolation, other +mechanisms like **Cynara** are required to check application's permissions at +runtime. Applicative permissions (also called "_privileges_") may vary depending +on the user and the application being run: an application should have access to +a given service only if it is run by the proper user and if the appropriate +permissions are granted. + +## Discretionary Access Control + +**D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux +method of separating users and groups from one another. In a shared environment +where multiple users have access to a computer or network, Unix IDs have offered +a way to contain access within privilege areas for individuals, or shared among +the group or system. The Android system took this one step further, assigning +new user IDs for each App. This was never the original intention of Linux UIDs, +but was able to provide Android’s initial security element: the ability to +sandbox applications. + +Although AGL mentions use of **DAC** for security isolation, the weight of the +security responsibility lies in the **M**andatory **A**ccess **C**ontrol +(**MAC**) and **Cynara**. Furthermore, there are system services with unique +UIDs. however,the system does not go to the extreme of Android, where every +application has its own UID. All sandboxing (app isolation) in AGL is handled in +the **MAC** contexts. + +## Mandatory Access Control + +**M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**, +whereby extended attributes (xattr) are associated with the filesystem. In the +case of AGL, the smackfs filesystem allows files and directories to be +associated with a SMACK label, providing the ability of further discrimination +on access control. A SMACK label is a simple null terminated character string +with a maximum of 255 bytes. While it doesn’t offer the richness of an SELinux +label, which provides a user, role,type, and level, the simplicity of a single +value makes the overall design far less complex. There is arguably less chance +of the security author making mistakes in the policies set forth. + +-------------------------------------------------------------------------------- + + + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | -------------------------------------------------------------- +_ACL_ | **A**ccess **C**ontrol **L**ists +_alsa_ | **A**dvanced **L**inux **S**ound **A**rchitecture +_API_ | **A**pplication **P**rogramming **I**nterface +_AppFw_ | **App**lication **F**rame**w**ork +_BSP_ | **B**oard **S**upport **P**ackage +_Cap_ | **Cap**abilities +_DAC_ | **D**iscretionary **A**ccess **C**ontrol +_DDOS_ | **D**istributed **D**enial **O**f **S**ervice +_DOS_ | **D**enial **O**f **S**ervice +_IPC_ | **I**nter-**P**rocess **C**ommunication +_MAC_ | **M**andatory **A**ccess **C**ontrol +_PAM_ | **P**luggable **A**uthentication **M**odules +_SMACK_ | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel + +# Mandatory Access Control + + + +We decided to put the **MAC** protection on the platform part despite the fact +that it applies to the kernel too, since its use will be mainly at the platform +level (except floor part). + + + +**M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the +Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL +uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol +**K**ernel (**SMACK**). This protection involves the creation of **SMACK** +labels as part of the extended attributes **SMACK** labels to the file extended +attributes. And a policy is also created to define the behaviour of each label. + +The kernel access controls is based on these labels and this policy. If there is +no rule, no access will be granted and as a consequence, what is not explicitly +authorized is forbidden. + +There are two types of **SMACK** labels: + +- **Execution SMACK** (Attached to the process): Defines how files are + _accessed_ and _created_ by that process. +- **File Access SMACK** (Written to the extended attribute of the file): Defines + _which_ process can access the file. + +By default a process executes with its File Access **SMACK** label unless an +Execution **SMACK** label is defined. + +AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System +into the following domains: + +- Floor. +- System. +- Applications, Services and User. + +See [AGL security framework +review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) +and [Smack White +Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf) +for more information. + +-------------------------------------------------------------------------------- + + + +## Floor + +The _floor_ domain includes the base system services and any associated data and +libraries. This data remains unchanged at runtime. Writing to floor files or +directories is allowed only in development mode or during software installation +or upgrade. + +The following table details the _floor_ domain: + +Label | Name | Execution **SMACK** | File Access **SMACK** +----- | ----- | ------------------- | --------------------------------------- +`-` | Floor | `r-x` for all | Only kernel and internal kernel thread. +`^` | Hat | `---` for all | `rx` on all domains. +`*` | Star | `rwx` for all | None + + + +- The Hat label is Only for privileged system services (currently only + systemd-journal). Useful for backup or virus scans. No file with this label + should exist except in the debug log. + +- The Star label is used for device files or `/tmp` Access restriction managed + via **DAC**. Individual files remain protected by their **SMACK** label. + + + +Domain | `Label` name | Recommendations +------------------ | ------------ | ----------------------------------------------------------- +Kernel-MAC-Floor-1 | `^` | Only for privileged system services. +Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. + + + +-------------------------------------------------------------------------------- + + + +## System + +The _system_ domain includes a reduced set of core system services of the OS and +any associated data. This data may change at runtime. + +The following table details the _system_ domain: + +Label | Name | Execution **SMACK** | File Access **SMACK** +---------------- | --------- | ----------------------------------------------- | --------------------- +`System` | System | None | Privileged processes +`System::Run` | Run | `rwxatl` for User and System label | None +`System::Shared` | Shared | `rwxatl` for system domain `r-x` for User label | None +`System::Log` | Log | `rwa` for System label `xa` for user label | None +`System::Sub` | SubSystem | Subsystem Config files | SubSystem only + + + +Domain | `Label` name | Recommendations +------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. +Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. +Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. +Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. +Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. + + + +-------------------------------------------------------------------------------- + + + +## Applications, Services and User + +The _application_, _services_ and _user_ domain includes code that provides +services to the system and user, as well as any associated data. All code +running on this domain is under _Cynara_ control. + +The following table details the _application_, _services_ and _user_ domain: + +Label | Name | Execution **SMACK** | File Access **SMACK** +------------------- | ------ | --------------------------------------------------------------------------- | --------------------------- +`User::Pkg::$AppID` | AppID | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App +`User::Home` | Home | `rwx-t` from System label `r-x-l` from App | None +`User::App-Shared` | Shared | `rwxat` from System and User domains label of $User | None + + + +Domain | `Label` name | Recommendations +------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. +Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. +Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. + + + +## Attack Vectors + +There are 4 major components to the system: + +- The LSM kernel module. +- The `smackfs` filesystem. +- Basic utilities for policy management and checking. +- The policy/configuration data. + +As with any mandatory access system, the policy management needs to be carefully +separated from the checking, as the management utilities can become a convenient +point of attack. Dynamic additions to the policy system need to be carefully +verified, as the ability to update the policies is often needed, but introduces +a possible threat. Finally, even if the policy management is well secured, the +policy checking and failure response to that checking is also of vital +importance to the smooth operation of the system. + +While **MAC** is a certainly a step up in security when compared to DAC, there +are still many ways to compromise a SMACK-enabled Linux system. Some of these +ways are as follows: + +- Disabling SMACK at invocation of the kernel (with command-line: + security=none). +- Disabling SMACK in the kernel build and redeploying the kernel. +- Changing a SMACK attribute of a file or directory at install time. +- Tampering with a process with the CAP_MAC_ADMIN privilege. +- Setting/Re-setting the SMACK label of a file. +- Tampering with the default domains (i.e. + /etc/smack/accesses.d/default-access-domains). +- Disabling or tampering with the SMACK filesystem (i.e. /smackfs). +- Adding policies with `smackload` (adding the utility if not present). +- Changing labels with `chsmack` (adding the utility if not present). + +# SystemD + +`afm-system-daemon` is used to: + +- Manage users and user sessions. +- Setup applications and services (_CGroups_, _namespaces_, autostart, + permissions). +- Use of `libsystemd` for its programs (event management, **D-Bus** interface). + + + +Domain | Object | Recommendations +------------------ | -------------- | ------------------------------------ +Platform-SystemD-1 | Security model | Use Namespaces for containerization. +Platform-SystemD-2 | Security model | Use CGroups to organise processes. + + + +See [systemd integration and user +management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for +more information. + +## Benefits + +- Removal of one privileged process: **afm-user-daemon** +- Access and use of high level features: + + - Socket activation. + - Management of users and integration of **PAM**. + - Dependency resolution to services. + - `Cgroups` and resource control. + - `Namespaces` containerization. + - Autostart of required API. + - Permissions and security settings. + - Network management. + + + +## CGroups + +Control Groups offer a lot of features, with the most useful ones you can +control: Memory usage, how much CPU time is allocated, how much device I/O is +allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise +processes (each service is a _CGroups_, and all processes started by that +service use that _CGroups_). By default, **SystemD** automatically creates a +hierarchy of slice, scope and service units to provide a unified structure for +the _CGroups_ tree. With the `systemctl` command, you can further modify this +structure by creating custom slices. Currently, in AGL, there are 2 slices +(**user.slice** and **system.slice**). + +## Namespaces + +### User side + +There are several ways of authenticating users (Key Radio Frequency, Phone, +Gesture, ...). Each authentication provides dynamic allocation of **uids** to +authenticated users. **Uids** is used to ensure privacy of users and **SMACK** +for applications privacy. + +First, the user initiates authentication with **PAM** activation. **PAM** +Standard offers highly configurable authentication with modular design like face +recognition, Voice identification or with a password. Then users should access +identity services with services and applications. + +# D-Bus + +D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and +daemon) that helps applications to talk to each other. The use of D-Bus is great +because it allows to implement discovery and signaling. + +The D-Bus session is by default addressed by environment variable +`DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable +`DBUS_SESSION_BUS_ADDRESS` is automatically set for user sessions. D-Bus usage +is linked to permissions. + +D-Bus has already had several [security +issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) +(mostly **DoS** issues), to allow applications to keep talking to each other. It +is important to protect against this type of attack to keep the system more +stable. + + + + +Domain | Object | Recommendations +--------------- | -------------- | ------------------------------------ +Platform-DBus-1 | Security model | Use D-Bus as IPC. +Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) + + + +# System services and daemons + + + +Domain | Improvement +------------------- | ----------- +Platform-Services-1 | SystemD ? +Platform-Services-2 | Secure daemon ? + + + +## Tools + +- **connman**: An internet connection manager designed to be slim and to use as + few resources as possible. It is a fully modular system that can be extended, + through plug-ins, to support all kinds of wired or wireless technologies. +- **bluez** is a Bluetooth stack. Its goal is to program an implementation of + the Bluetooth wireless standards specifications. In addition to the basic + stack, the `bluez-utils` and `bluez-firmware` packages contain low level + utilities such as `dfutool` which can interrogate the Bluetooth adapter + chipset in order to determine whether its firmware can be upgraded. +- **gstreamer** is a pipeline-based multimedia framework. It can be used to + build a system that reads files in one format, processes them, and exports + them in another format. +- **alsa** is a software framework and part of the Linux kernel that provides an + **API** for sound card device drivers. + + + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ------- +Platform-Utilities-1 | `connman` | _Used_ as a connection manager. +Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. +Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. +Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. + + + +# Application framework/model (**AppFw**) + +The AGL application framework consists of several inter-working parts: + +- **SMACK**: The kernel level **LSM** (**L**inux **S**ecurity **M**odule) that + performs extended access control of the system. +- **Cynara**: the native gatekeeper daemon used for policy handling, updating to + the database and policy checking. +- Security Manager: a master service, through which all security events are + intended to take place. +- Several native application framework utilities: `afm-main-binding`, + `afm-user-daemon`, `afm-system-daemon`. + +The application framework manages: + +- The applications and services management: Installing, Uninstalling, Listing, + ... +- The life cycle of applications: Start -> (Pause, Resume) -> Stop. +- Events and signals propagation. +- Privileges granting and checking. +- API for interaction with applications. + + + +- The **security model** refers to the security model used to ensure security + and to the tools that are provided for implementing that model. It's an + implementation detail that should not impact the layers above the application + framework. + +- The **security model** refers to how **DAC** (**D**iscretionary **A**ccess + **C**ontrol), **MAC** (Mandatory Access Control) and `Capabilities` are used + by the system to ensure security and privacy. It also includes features of + reporting using audit features and by managing logs and alerts. + + + +The **AppFw** uses the security model to ensure the security and the privacy of +the applications that it manages. It must be compliant with the underlying +security model. But it should hide it to the applications. + + + +Domain | Object | Recommendations +---------------------- | -------------- | -------------------------------- +Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. + + + +See [AGL AppFw Privileges +Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) +and [AGL - Application Framework +Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) +for more information. + + + +The Security Manager communicates policy information to **Cynara**, which +retains information in its own database in the format of a text file with +comma-separated values (CSV). There are provisions to retain a copy of the CSV +text file when the file is being updated. + +Runtime checking occurs through **Cynara**. Each application that is added to +the framework has its own instantiation of a SMACK context and D-bus bindings. +The afb_daemon and Binder form a web-service that is communicated to through +http or a websocket from the application-proper. This http or websocket +interface uses a standard unique web token for API communication. + +![Application Framework Flow](images/App-flow.png) + +## Cynara + +There's a need for another mechanism responsible for checking applicative +permissions: Currently in AGL, this task depends on a policy-checker service +(**Cynara**). + +- Stores complex policies in databases. +- "Soft" security (access is checked by the framework). + +Cynara interact with **D-Bus** in order to deliver this information. + +Cynara consists of several parts: + +- Cynara: a daemon for controlling policies and responding to access control + requests. +- Database: a spot to hold policies. +- Libraries: several static and dynamic libraries for communicating with Cynara. + +The daemon communicates to the libraries over Unix domain sockets. The database +storage format is a series of CSV-like files with an index file. + +There are several ways that an attacker can manipulate policies of the Cynara +system: + +- Disable Cynara by killing the process. +- Tamper with the Cynara binary on-disk or in-memory. +- Corrupt the database controlled by Cynara. +- Tamper with the database controlled by Cynara. +- Highjack the communication between Cynara and the database. + +The text-based database is the weakest part of the system and although there are +some consistency mechanisms in place (i.e. the backup guard), these mechanisms +are weak at best and can be countered by an attacker very easily. + + + +Domain | Object | Recommendations +----------------------- | ----------- | ------------------------------------- +Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. + + + +### Policies + +- Policy rules: + + - Are simple - for pair [application context, privilege] there is straight + answer (single Policy Type): [ALLOW / DENY / ...]. + - No code is executed (no script). + - Can be easily cached and managed. + +- Application context (describes id of the user and the application credentials) + It is build of: + + - UID of the user that runs the application. + - **SMACK** label of application. + +## Holding policies + +Policies are kept in buckets. Buckets are set of policies which have additional +a property of default answer, the default answer is yielded if no policy matches +searched key. Buckets have names which might be used in policies (for +directions). + +## Attack Vectors + +The following attack vectors are not completely independent. While attackers may +have varying levels of access to an AGL system, experience has shown that a +typical attack can start with direct access to a system, find the +vulnerabilities, then proceed to automate the attack such that it can be invoked +from less accessible standpoint (e.g. remotely). Therefore, it is important to +assess all threat levels, and protect the system appropriately understanding +that direct access attacks are the door-way into remote attacks. + +### Remote Attacks + +The local web server interface used for applications is the first point of +attack, as web service APIs are well understood and easily intercepted. The +local web server could potentially be exploited by redirecting web requests +through the local service and exploiting the APIs. While there is the use of a +security token on the web service API, this is weak textual matching at best. +This will not be difficult to spoof. It is well known that [API Keys do not +provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/). + +It is likely that the architectural inclusion of an http / web-service interface +provided the most flexibility for applications to be written natively or in +HTML5. However, this flexibility may trade-off with security concerns. For +example, if a native application were linked directly to the underlying +framework services, there would be fewer concerns over remote attacks coming +through the web-service interface. + +Leaving the interface as designed, mitigations to attacks could include further +securing the interface layer with cryptographic protocols: e.g. encrypted +information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman). + +### User-level Native Attacks + +- Modifying the CSV data-base +- Modifying the SQLite DB +- Tampering with the user-level binaries +- Tampering with the user daemons +- Spoofing the D-bus Interface +- Adding executables/libraries + +With direct access to the device, there are many security concerns on the native +level. For example, as **Cynara** uses a text file data-base with +comma-separated values (CSV), an attacker could simply modify the data-base to +escalate privileges of an application. Once a single application has all the +privileges possible on the system, exploits can come through in this manner. +Similarly the SQLite database used by the Security Manager is not much different +than a simple text file. There are many tools available to add, remove, modify +entries in an SQLite data-base. + +On the next level, a common point of attack is to modify binaries or daemons for +exploiting functionality. There are many Linux tools available to aid in this +regard, including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml), +and [radare2](https://rada.re/r/). With the ability to modify binaries, an +attacker can do any number of activities including: removing calls to security +checks, redirecting control to bypass verification functionality, ignoring +security policy handling, escalating privileges, etc. + +Additionally, another attack vector would be to spoof the D-bus interface. D-bus +is a message passing system built upon Inter-Process Communication (IPC), where +structured messages are passed based upon a protocol. The interface is generic +and well documented. Therefore, modifying or adding binaries/libraries to spoof +this interface is a relatively straight-forward process. Once the interface has +been spoofed, the attacker can issue any number of commands that lead into +control of low-level functionality. + +Protecting a system from native attacks requires a methodical approach. First, +the system should reject processes that are not sanctioned to run. +Signature-level verification at installation time will help in this regard, but +run-time integrity verification is much better. Signatures need to originate +from authorized parties, which is discussed further in a later section on the +Application Store. + +On the next level, executables should not be allowed to do things where they +have not been granted permission. DAC and SMACK policies can help in this +regard. On the other hand, there remain concerns with memory accesses, system +calls, and other process activity that may go undetected. For this reason, a +secure environment which monitors all activity can give indication of all +unauthorized activity on the system. + +Finally, it is very difficult to catch attacks of direct tampering in a system. +These types of attacks require a defense-in-depth approach, where complementary +software protection and hardening techniques are needed. Tamper-resistance and +anti-reverse-engineering technologies include program +transformations/obfuscation, integrity verification, and white-box cryptography. +If applied in a mutually-dependent fashion and considering performance/security +tradeoffs, the approach can provide an effective barrier to direct attacks to +the system. Furthermore, the use of threat monitoring provides a valuable +telemetry/analytics capability and the ability to react and renew a system under +attack. + +### Root-level Native Attacks + +- Tampering the system daemon +- Tampering Cynara +- Tampering the security manager +- Disabling SMACK +- Tampering the kernel + +Once root-level access (i.e. su) has been achieved on the device, there are many +ways to compromise the system. The system daemon, **Cynara**, and the security +manager are vulnerable to tampering attacks. For example, an executable can be +modified in memory to jam a branch, jump to an address, or disregard a check. +This can be as simple as replacing a branch instruction with a NOP, changing a +memory value, or using a debugger (e.g. gdb, IDA) to change an instruction. +Tampering these executables would mean that policies can be ignored and +verification checks can be bypassed. + +Without going so far as to tamper an executable, the **SMACK** system is also +vulnerable to attack. For example, if the kernel is stopped and restarted with +the *security=none* flag, then SMACK is not enabled. Furthermore, `systemd` +starts the loading of **SMACK** rules during start-up. If this start-up process +is interfered with, then **SMACK** will not run. Alternatively, new policies can +be added with `smackload` allowing 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`. + +# Utilities + +- **busybox**: Software that provides several stripped-down Unix tools in a + single executable file. Of course, it will be necessary to use a "production" + version of **busybox** in order to avoid all the tools useful only in + development mode. + + + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ---------------------------------------------------------------------- +Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. + + + +## Functionalities to exclude in production mode + +In production mode, a number of tools must be disabled to prevent an attacker +from finding logs for example. This is useful to limit the visible surface and +thus complicate the fault finding process. The tools used only in development +mode are marked by an '**agl-devel**' feature. When building in production mode, +these tools will not be compiled. + + + +Domain | `Utility` name and normal `path` | _State_ +--------------------- | ---------------------------------------------------- | ---------- +Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ +Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ +Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ +Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ +Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ +Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ +Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ +Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ +Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ +Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ +Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ +Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ +Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ +Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ +Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ +Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ +Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ +Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ +Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ +Platform-Utilities-22 | `SSH` | _Disabled_ +Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ +Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ +Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ +Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ +Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ +Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ +Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ +Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ +Platform-Utilities-31 | `awk` (busybox) | _Enabled_ +Platform-Utilities-32 | `cut` (busybox) | _Enabled_ +Platform-Utilities-33 | `df` (busybox) | _Enabled_ +Platform-Utilities-34 | `echo` (busybox) | _Enabled_ +Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ +Platform-Utilities-36 | `grep` (busybox) | _Enabled_ +Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ +Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ +Platform-Utilities-39 | `printf` (busybox) | _Enabled_ +Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ +Platform-Utilities-41 | `tail` (busybox) | _Enabled_ +Platform-Utilities-42 | `tee` (busybox) | _Enabled_ +Platform-Utilities-43 | `test` (busybox) | _Enabled_ + + + +The _Enabled_ Unix/Linux utilities above shall be permitted as they are often +used in the start-up scripts and for USB logging. If any of these utilities are +not required by the device then those should be removed. + + + +# Users + +The user policy can group users by function within the car. For example, we can +consider a driver and his passengers. Each user is assigned to a single group to +simplify the management of space security. + +## Root Access + +The main applications, those that provide the principal functionality of the +embedded device, should not execute with root identity or any capability. + +If the main application is allowed to execute at any capability, then the entire +system is at the mercy of the said application's good behaviour. Problems arise +when an application is compromised and able to execute commands which could +consistently and persistently compromise the system by implanting rogue +applications. + +It is suggested that the middleware and the UI should run in a context on a user +with no capability and all persistent resources should be maintained without any +capability. + +One way to ensure this is by implementing a server-client paradigm. Services +provided by the system's drivers can be shared this way. The other advantage of +this approach is that multiple applications can share the same resources at the +same time. + + + +Domain | Object | Recommendations +--------------------- | ---------------- | ----------------------------------------------------- +Platform-Users-root-1 | Main application | Should not execute as root. +Platform-Users-root-2 | UI | Should run in a context on a user with no capability. + + + +Root access should not be allowed for the following utilities: + + + +Domain | `Utility` name | _State_ +--------------------- | -------------- | ------------- +Platform-Users-root-3 | `login` | _Not allowed_ +Platform-Users-root-4 | `su` | _Not allowed_ +Platform-Users-root-5 | `ssh` | _Not allowed_ +Platform-Users-root-6 | `scp` | _Not allowed_ +Platform-Users-root-7 | `sftp` | _Not allowed_ + + + +Root access should not be allowed for the console device. The development +environment should allow users to login with pre-created user accounts. + +Switching to elevated privileges shall be allowed in the development environment +via `sudo`. + +-------------------------------------------------------------------------------- + + + +## Capabilities + + + +Domain | Improvement +----------------------------- | ------------------------ +Platform-Users-Capabilities-1 | Kernel or Platform-user? +Platform-Users-Capabilities-2 | Add config note. + + + +The goal is to restrict functionality that will not be useful in **AGL**. They +are integrated into the **LSM**. Each privileged transaction is associated with +a capability. These capabilities are divided into three groups: + +- e: Effective: This means the capability is “activated”. +- p: Permitted: This means the capability can be used/is allowed. +- i: Inherited: The capability is kept by child/subprocesses upon execve() for + example. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md b/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md new file mode 100644 index 0000000..c08d06e --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md @@ -0,0 +1,125 @@ +--- +title: Application +--- + +**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. + +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 containment is achieved using the following protections: + +- Linux Native protection + - Mandatory Access Control (**MAC**) +- AGL Platform protections + - Origin Tracking and Validation + - Application Privilege Management and Enforcement via Cynara + - Authenticated Transport via D-Bus + +## 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 (**AppFw**) consists of a number of utilities and daemons +which provide context for the applications. Isolation is provided through +**SMACK** labels. + +## 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. + +![App Signing Flow](images/App_signing_flow.png) + +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. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | ---------------------------------------------------- +_3GPP_ | **3**rd **G**eneration **P**artnership **P**roject +_CASB_ | **C**loud **A**ccess **S**ecurity **B**roker +_DAST_ | **D**ynamic **A**pplication **S**ecurity **T**esting +_DPI_ | **D**eep **P**acket **I**nspection +_IDS_ | **I**ntrusion **D**etection **S**ystems +_IPS_ | **I**ntrusion **P**revention **S**ystems +_IPSec_ | **I**nternet **P**rotocol **Sec**urity +_LSM_ | **L**inux **S**ecurity **M**odule +_MITM_ | **M**an **I**n **T**he **M**iddle +_OSI_ | **O**pen **S**ystems **I**nterconnection +_SATS_ | **S**tatic **A**pplication **S**ecurity **T**esting + +# Local + +Domain | Improvement +-------------------------- | ------------------------------ +Application-Installation-1 | Talk about AppFw offline mode. + +## Installation + +Applications can be delivered and installed with the base image using a special +offline-mode provided by the **AppFw**. Apps can also be installed at run time. + +During early release, default Apps are installed on the image at first boot. + +Domain | Object | Recommendations +-------------------------- | --------- | ----------------------------------------------------------------------- +Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. +Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. + +# Local + +## Privilege Management + +Application privileges are managed by **Cynara** and the security manager in the +**AppFw**. For more details, please refer to the **AppFw** documentation in +Platform part. + +# App Signature + +Domain | Improvement +----------------------- | ---------------------------------------------------------- +Application-Signature-1 | Add content (see secure build in Secure development part). + + +# Services + +Domain | Improvement +---------------------- | ------------ +Application-Services-1 | Add content (Which services?). +Application-Services-2 | Add Binder. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md b/docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md new file mode 100644 index 0000000..076c0e0 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md @@ -0,0 +1,487 @@ +--- +title: Connectivity +--- + +This part shows different Connectivity attacks on the car. + +Domain | Improvement +----------------------- | ----------------- +Connectivity-Abstract-1 | Improve abstract. + + + +-------------------------------------------------------------------------------- + + + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | --------------------------------------------------------------------------------- +_ARP_ | **A**ddress **R**esolution **P**rotocol +_BLE_ | **B**luetooth **L**ow **E**nergy +_CAN_ | **C**ar **A**rea **N**etwork +_CCMP_ | **C**ounter-Mode/**C**BC-**M**ac **P**rotocol +_EDGE_ | **E**nhanced **D**ata **R**ates for **GSM** **E**volution - Evolution of **GPRS** +_GEA_ | **G**PRS **E**ncryption **A**lgorithm +_GPRS_ | **G**eneral **P**acket **R**adio **S**ervice (2,5G, 2G+) +_GSM_ | **G**lobal **S**ystem for **M**obile Communications (2G) +_HSPA_ | **H**igh **S**peed **P**acket **A**ccess (3G+) +_IMEI_ | **I**nternational **M**obile **E**quipment **I**dentity +_LIN_ | **L**ocal **I**nterconnect **N**etwork +_MOST_ | **M**edia **O**riented **S**ystem **T**ransport +_NFC_ | **N**ear **F**ield **C**ommunication +_OBD_ | **O**n-**B**oard **D**iagnostics +_PATS_ | **P**assive **A**nti-**T**heft **S**ystem +_PKE_ | **P**assive **K**eyless **E**ntry +_PSK_ | **P**hase-**S**hift **K**eying +_RDS_ | **R**adio **D**ata **S**ystem +_RFID_ | **R**adio **F**requency **I**dentification +_RKE_ | **R**emote **K**eyless **E**ntry +_SDR_ | **S**oftware **D**efined **R**adio +_SSP_ | **S**ecure **S**imple **P**airing +_TKIP_ | **T**emporal **K**ey **I**ntegrity **P**rotocol +_TPMS_ | **T**ire **P**ressure **M**onitoring **S**ystem +_UMTS_ | **U**niversal **M**obile **T**elecommunications **S**ystem (3G) +_USB_ | **U**niversal **S**erial **B**us +_WEP_ | **W**ired **E**quivalent **P**rivacy +_WPA_ | **W**ifi **P**rotected **A**ccess + +# Bus + +We only speak about the **CAN** bus to take an example, because the different +attacks on bus like _FlewRay_, _ByteFlight_, _Most_ and _Lin_ use retro +engineering and the main argument to improve their security is to encrypt data +packets. We just describe them a bit: + +- **CAN**: Controller Area Network, developed in the early 1980s, is an + event-triggered controller network for serial communication with data rates up + to one MBit/s. **CAN** messages are classified over their respective + identifier. **CAN** controller broadcast their messages to all connected nodes + and all receiving nodes decide independently if they process the message. +- **FlewRay**: Is a deterministic and error-tolerant high-speed bus. With a data + rate up to 10 MBit/s. +- **ByteFlight**: Is used for safety-critical applications in motor vehicles + like air-bags. Byteflight runs at 10Mbps over 2 or 3 wires plastic optical + fibers. +- **Most**: Media Oriented System Transport, is used for transmitting audio, + video, voice, and control data via fiber optic cables. The speed is, for the + synchronous way, up to 24 MBit/s and asynchronous way up to 14 MBit/s. + **MOST** messages include always a clear sender and receiver address. +- **LIN**: Local Interconnect Network, is a single-wire subnet work for + low-cost, serial communication between smart sensors and actuators with + typical data rates up to 20 kBit/s. It is intended to be used from the year + 2001 on everywhere in a car, where the bandwidth and versatility of a **CAN** + network is not required. + +On just about every vehicle, **ECU**s (**E**lectronic **C**ontrol **U**nits) +communicate over a CAN 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. + + + +Domain | Tech name | Recommendations +---------------------------------- | --------- | -------------------------------------------------------------------------- +Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. + + + +See [Security in Automotive Bus +Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf) +for more information. + +# Connectors + +For the connectors, we supposed that they were disabled by default. For example, +the **USB** must be disabled to avoid attacks like BadUSB. If not, configure the +Kernel to only enable the minimum require **USB** devices. The connectors used +to diagnose the car like **OBD-II** must be disabled outside garages. + + + +Domain | Tech name | Recommendations +----------------------------------------- | --------- | ---------------------------------------------------------------------- +Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. +Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. +Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. +Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. + + + +# Wireless + +In this part, we talk about possible remote attacks on a car, according to the +different areas of possible attacks. For each communication channels, we +describe attacks and how to prevent them with some recommendations. The main +recommendation is to always follow the latest updates of these remote +communication channels. + + + +Domain | Object | Recommendations +----------------------- | ------ | ------------------------------------------------------------------ +Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. + + + +We will see the following parts: + +- [Wifi](#wifi) + +- [Bluetooth](#bluetooth) + +- [Cellular](#cellular) + +- [Radio](#radio) + +- [NFC](#nfc) + + + +Domain | Improvement +----------------------- | ------------------------------------------- +Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). + + + +-------------------------------------------------------------------------------- + +For existing automotive-specific means, we take examples of existing system +attacks from the _IOActive_ document ([A Survey of Remote Automotive Attack +Surfaces](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf)) +and from the ETH document ([Relay Attacks on Passive Keyless Entry and Start +Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf)). + +- [Telematics](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A40%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) + +- [Passive Anti-Theft System + (PATS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A11%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C574%2C0%5D) + +- [Tire Pressure Monitoring System + (TPMS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A17%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) + +- [Remote Keyless Entry/Start + (RKE)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A26%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) + +- [Passive Keyless Entry (PKE)](https://eprint.iacr.org/2010/332.pdf) + +-------------------------------------------------------------------------------- + + + +## Wifi + +### Attacks + +We can differentiate existing attacks on wifi in two categories: Those on +**WEP** and those on **WPA**. + +- **WEP** attacks: + + - **FMS**: (**F**luhrer, **M**antin and **S**hamir attack) is a "Stream cipher + attack on the widely used RC4 stream cipher. The attack allows an attacker + to recover the key in an RC4 encrypted stream from a large number of + messages in that stream." + - **KoreK**: "Allows the attacker to reduce the key space". + - **PTW**: (**P**yshkin **T**ews **W**einmann attack). + - **Chopchop**: Found by KoreK, "Weakness of the CRC32 checksum and the lack + of replay protection." + - **Fragmentation** + +- **WPA** attacks: + + - **Beck and Tews**: Exploit weakness in **TKIP**. "Allow the attacker to + decrypt **ARP** packets and to inject traffic into a network, even allowing + him to perform a **DoS** or an **ARP** poisoning". + - [KRACK](https://github.com/kristate/krackinfo): (K)ey (R)einstallation + (A)tta(ck) ([jira AGL + SPEC-1017](https://jira.automotivelinux.org/browse/SPEC-1017)). + +### Recommendations + +- Do not use **WEP**, **PSK** and **TKIP**. + +- Use **WPA2** with **CCMP**. + +- Should protect data sniffing. + + + +Domain | Tech name or object | Recommendations +---------------------------- | ------------------- | ------------------------------------------------------------------------- +Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled +Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used +Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. +Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. +Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. + + + +See [Wifi attacks WEP WPA](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf) and +[Breaking wep and wpa (Beck and +Tews)](https://dl.aircrack-ng.org/breakingwepandwpa.pdf) for more information. + +-------------------------------------------------------------------------------- + + + +## Bluetooth + +### Attacks + +- **Bluesnarfing** attacks involve an attacker covertly gaining access to your + Bluetooth-enabled device for the purpose of retrieving information, including + addresses, calendar information or even the device's **I**nternational + **M**obile **E**quipment **I**dentity. With the **IMEI**, an attacker could + route your incoming calls to his cell phone. +- **Bluebugging** is a form of Bluetooth attack often caused by a lack of + awareness. Similar to bluesnarfing, bluebugging accesses and uses all phone + features but is limited by the transmitting power of class 2 Bluetooth radios, + normally capping its range at 10-15 meters. +- **Bluejacking** is the sending of unsolicited messages. +- **BLE**: **B**luetooth **L**ow **E**nergy + [attacks](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf). +- **DoS**: Drain a device's battery or temporarily paralyze the phone. + +### Recommendations + +- Not allowing Bluetooth pairing attempts without the driver's first manually + placing the vehicle in pairing mode. +- Monitoring. +- Use **BLE** with caution. +- For v2.1 and later devices using **S**ecure **S**imple **P**airing (**SSP**), + avoid using the "Just Works" association model. The device must verify that an + authenticated link key was generated during pairing. + + + +Domain | Tech name | Recommendations +--------------------------------- | ------------- | ------------------------------------------------------------ +Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. +Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring +Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. +Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. +Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. + + + +See [Low energy and the automotive +transformation](http://www.ti.com/lit/wp/sway008/sway008.pdf), [Gattacking +Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf), [Comprehensive +Experimental Analyses of Automotive Attack +Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf) and [With Low +Energy comes Low +Security](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf) +for more information. + +-------------------------------------------------------------------------------- + + + +## Cellular + +### Attacks + +- **IMSI-Catcher**: Is a telephone eavesdropping device used for intercepting + mobile phone traffic and tracking location data of mobile phone users. + Essentially a "fake" mobile tower acting between the target mobile phone and + the service provider's real towers, it is considered a man-in-the-middle + (**MITM**) attack. + +- Lack of mutual authentication (**GPRS**/**EDGE**) and encryption with + **GEA0**. + +- **Fall back** from **UMTS**/**HSPA** to **GPRS**/**EDGE** (Jamming against + **UMTS**/**HSPA**). + +- 4G **DoS** attack. + +### Recommendations + +- Check antenna legitimacy. + + + +Domain | Tech name | Recommendations +-------------------------------- | --------- | -------------------------- +Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid +Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. + + + +See [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data +communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf) +for more information. + +-------------------------------------------------------------------------------- + +## Radio + +### Attacks + +- Interception of data with low cost material (**SDR** with hijacked DVB-T/DAB + for example). + +### Recommendations + +- Use the **R**adio **D**ata **S**ystem (**RDS**) only to send signals for audio + output and meta concerning radio. + + + +Domain | Tech name | Recommendations +----------------------------- | --------- | -------------------------------------------- +Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. + + + +-------------------------------------------------------------------------------- + + + +## NFC + +### Attacks + +- **MITM**: Relay and replay attack. + +### Recommendations + +- Should implements protection against relay and replay attacks (Tokens, + etc...). +- Disable unneeded and unapproved services and profiles. +- NFC should be use encrypted link (secure channel). A standard key agreement + protocol like Diffie-Hellmann based on RSA or Elliptic Curves could be applied + to establish a shared secret between two devices. +- Automotive NFC device should be certified by NFC forum entity: The NFC Forum + Certification Mark shows that products meet global interoperability standards. +- NFC Modified Miller coding is preferred over NFC Manchester coding. + + + +Domain | Tech name | Recommendations +--------------------------- | --------- | ------------------------------------------------------ +Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. +Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. + + + +# Cloud + +## Download + +- **authentication**: Authentication is the security process that validates the + claimed identity of a device, entity or person, relying on one or more + characteristics bound to that device, entity or person. + +- **Authorization**: Parses the network to allow access to some or all network + functionality by providing rules and allowing access or denying access based + on a subscriber's profile and services purchased. + + + +Domain | Object | Recommendations +---------------------------- | -------------- | -------------------------------------- +Application-Cloud-Download-1 | authentication | Must implement authentication process. +Application-Cloud-Download-2 | Authorization | Must implement Authorization process. + + + +-------------------------------------------------------------------------------- + +## Infrastructure + +- **Deep Packet Inspection**: **DPI** provides techniques to analyze the payload + of each packet, adding an extra layer of security. **DPI** can detect and + neutralize attacks that would be missed by other security mechanisms. + +- A **DoS** protection in order to avoid that the Infrastructure is no more + accessible for a period of time. + +- **Scanning tools** such as **SATS** and **DAST** assessments perform + vulnerability scans on the source code and data flows on web applications. + Many of these scanning tools run different security tests that stress + applications under certain attack scenarios to discover security issues. + +- **IDS & IPS**: **IDS** detect and log inappropriate, incorrect, or anomalous + activity. **IDS** can be located in the telecommunications networks and/or + within the host server or computer. Telecommunications carriers build + intrusion detection capability in all network connections to routers and + servers, as well as offering it as a service to enterprise customers. Once + **IDS** systems have identified an attack, **IPS** ensures that malicious + packets are blocked before they cause any harm to backend systems and + networks. **IDS** typically functions via one or more of three systems: + + 1. Pattern matching. + 2. Anomaly detection. + 3. Protocol behavior. + + + + + +Domain | Object | Recommendations +---------------------------------- | ------------- | ---------------------------------------------------------- +Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. +Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. +Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. +Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). +Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. + + + +-------------------------------------------------------------------------------- + +## Transport + +For data transport, it is necessary to **encrypt data end-to-end**. To prevent +**MITM** attacks, no third party should be able to interpret transported data. +Another aspect is the data anonymization in order to protect the leakage of +private information on the user or any other third party. + +The use of standards such as **IPSec** provides "_private and secure +communications over IP networks, through the use of cryptographic security +services, is a set of protocols using algorithms to transport secure data over +an IP network._". In addition, **IPSec** operates at the network layer of the +**OSI** model, contrary to previous standards that operate at the application +layer. This makes its application independent and means that users do not need +to configure each application to **IPSec** standards. + +**IPSec** provides the services below : + +- Confidentiality: A service that makes it impossible to interpret data if it is + not the recipient. It is the encryption function that provides this service by + transforming intelligible (unencrypted) data into unintelligible (encrypted) + data. +- Authentication: A service that ensures that a piece of data comes from where + it is supposed to come from. +- Integrity: A service that consists in ensuring that data has not been tampered + with accidentally or fraudulently. +- Replay Protection: A service that prevents attacks by re-sending a valid + intercepted packet to the network for the same authorization. This service is + provided by the presence of a sequence number. +- Key management: Mechanism for negotiating the length of encryption keys + between two **IPSec** elements and exchange of these keys. + +An additional means of protection would be to do the monitoring between users +and the cloud as a **CASB** will provide. + + + +Domain | Object | Recommendations +----------------------------- | ----------------------------------------- | --------------------------------- +Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. + diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md b/docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md new file mode 100644 index 0000000..60ae8e4 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md @@ -0,0 +1,154 @@ +--- +title: Update (Over The Air) +--- + +Updating applications and firmware is essential for the development of new +features and even more to fix security bugs. However, if a malicious third party +manages to alter the content during transport, it could alter the functioning of +the system and/or applications. The security of the updates is therefore a +critical point to evaluate in order to guarantee the integrity, the +confidentiality and the legitimacy of the transmitted data. + +## Attack Vectors + +Updates 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 back-end. +* 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) + +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. + +-------------------------------------------------------------------------------- + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | ------------------------------------------------------------------------- +_FOTA_ | **F**irmware **O**ver **T**he **A**ir +_MATE_ | **M**an **A**t **T**he **E**nd +_MITM_ | **M**an **I**n **T**he **M**iddle +_OTA_ | **O**ver **T**he **A**ir +_SOTA_ | **S**oftware **O**ver **T**he **A**ir +_TUF_ | **T**he **U**pdate **F**ramework + +# Firmware Over The Air + +The firmware update is critical since its alteration back to compromise the +entire system. It is therefore necessary to take appropriate protective +measures. + +AGL includes the _meta-updater_ Yocto layer that enables OTA software updates +via [Uptane](https://uptane.github.io), an automotive-specific extension to [The +Update Framework](https://theupdateframework.github.io/). Uptane and TUF are +open standards that define a secure protocol for delivering and verifying +updates even when the servers and network--internet and car-internal--aren't +fully trusted. + +_meta-updater_ includes the application +[`aktualizr`](https://github.com/advancedtelematic/aktualizr), developed +Advanced Telematic Systems (now part of HERE Technologies) that enables OTA for +an ECU. `aktualizr` combined with Uptane is suitable for updating the firmware, +software, and other packages on even functionally critical ECUs. `aktualizr` can +be enabled with the free, open souce backend +[`ota-community-edition`](https://github.com/advancedtelematic/ota-community-edition). + +This FOTA update mechanism can be enabled through the `agl-sota` feature. + +## Building + +To build an AGL image that uses `aktualizr`, the following can be used. + +``` +source meta-agl/scripts/aglsetup.sh -m agl-sota +``` + +During the build, _meta-updater_ will use credentials downloaded from +`ota-community-edition` to sign metadata verifying the build as authentic. These +signatures are part of the Uptane framework and are used to verify FOTA updates. + +## Atomic Upgrades with Rollbacks + +`aktualizr`'s primary method of updating firmware is to use `libostree` with +binary diffs. The binary diffs use the least amout of bandwidth, and by it's +nature `libostree` stores current and previous firmware versions on disk or in +flash memory to allow for rollbacks. + +`libostree` is a content addressable object store much like `git`. Versions are +specified via SHA2-256. These hashes are signed in the Uptane metadata and are +robust against cryptographic compromise. + +# Software Over The Air + +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 **OTA** update model, securing these processes becomes a high +priority. + +**SOTA** is made possible by **AppFw** (See Platform part). It will be possible +to manage in a simple way the packets (i.g. Android like). + +Domain | Improvement +------------- | ----------------- +Update-SOTA-1 | Part to complete. \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md b/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md new file mode 100644 index 0000000..9cbe3b4 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md @@ -0,0 +1,58 @@ +--- +title: Secure development +--- + +In order to save a lot of time in code auditing, developers must follow coding +guidelines. + +## Secure build + +### Kernel build + +Tools like: + +- [Code optimisation](https://github.com/jduck/lk-reducer). +- [Kernel Drivers test](https://github.com/ucsb-seclab/dr_checker) with + [docs](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pdf). + +Domain | Improvement +----------------------- | ------------ +SecureDev-SecureBuild-1 | Add content. + +## App/Widget signatures + +Domain | Improvement +---------------------- | ------------ +SecureDev-Signatures-1 | Add content. + +## Code audit + +These tools are used to check the correct implementation of functionalities and +compliance with related good practices. + +- [Continuous Code Quality](https://www.sonarqube.org/). + +Domain | Improvement +--------------------- | ----------------------------------------------------- +SecureDev-CodeAudit-1 | Add CVE analyser. +SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). + +### SATS + +- [RATS](https://github.com/andrew-d/rough-auditing-tool-for-security) (Maybe to + old). +- [Flaw Finder](https://www.dwheeler.com/flawfinder/). + +- [wiki + list](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis). + +- [Mathematical + approach](https://perso.univ-rennes1.fr/david.lubicz/planches/David_Pichardie.pdf). + +It is necessary to verify that the application code does not use functions that +are depreciated and recognized as unsecured or cause problems. + +### DATS + +- [wiki + list](https://en.wikipedia.org/wiki/Dynamic_program_analysis#Example_tools). \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md b/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md new file mode 100644 index 0000000..c279203 --- /dev/null +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md @@ -0,0 +1,578 @@ +--- +title: Annexes +--- + +The first part resumed all the configurations you must implement without any +explications since all the explanations are given as and when in the document. + +- The _config_ tag quickly identifies the configurations and the recommendations + to take. + +- The _note_ tag allows you to notify some additional details. + +- The _todo_ tag shows the possible improvements. + +The second one allows to visualize all the todo notes in order to have a global +vision of the possible improvements of the document. + +# Config notes + + +Domain | Object | Recommendations +-------------------- | ---------- | ---------------------------------- +Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. +Hardware-Integrity-2 | Board | Must use a HSM. +Hardware-Integrity-3 | RTC | Must not be alterable. + +Domain | Object | Recommendations +---------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. +Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. +Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. + +Domain | Object | Recommendations +----------------- | ---------- | ------------------------------------------------------------------------------------ +Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys. +Hardware-Memory-2 | Bootloader | Internal NVM only +Hardware-Module-3 | - | HSM must be used to secure keys. + +Domain | _Variable_ / `Config` name | `Value` +---------------------- | -------------------------- | ------- +Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` +Boot-Image-Selection-2 | _bootdelay_ | `-2` + +Domain | `Config` name | _State_ +------------------------- | ---------------------------- | -------- +Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_ +Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_ +Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_ +Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ +Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ +Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ + +Domain | Communication modes | _State_ +-------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- +Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required. +Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care. +Boot-Communication-3 | `Ethernet` | _Disabled_ +Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ +Boot-Communication-5 | `Serial ports` | _Disabled_ + +Domain | `Config` name | _State_ +------------------------ | ----------------------- | ------------- +Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_ +Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_ +Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_ +Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_ +Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ + +Domain | Communication modes | _State_ +-------------------- | -------------------- | --------------------------------------------------------------------------------------------- +Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. + +Domain | Object | Recommendations +-------------------- | --------------------------------- | ------------------------------------------------------------- +Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. + +Domain | `Command` name | _State_ +-------------------------- | -------------- | --------- +Boot-Communication-Flash-1 | `do_nand` | _Disable_ + +Domain | `Config` name | `Value` +---------------------- | --------------------------------------- | --------- +Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable` +Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable` +Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable` + +Domain | `Environment variable` name | _State_ +---------------------- | --------------------------- | ------------- +Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ + +Domain | `Config` name | _State_ +-------------------------- | ---------------------------- | --------- +Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef` +Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef` +Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef` +Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef` +Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef` +Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef` +Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef` +Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef` +Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef` +Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef` +Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef` +Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define` + +Domain | `Command` name | _State_ +----------------------- | -------------- | ---------- +Boot-Consoles-MemDump-1 | `md` | _Disabled_ +Boot-Consoles-MemDump-2 | `mm` | _Disabled_ +Boot-Consoles-MemDump-3 | `nm` | _Disabled_ +Boot-Consoles-MemDump-4 | `mw` | _Disabled_ +Boot-Consoles-MemDump-5 | `cp` | _Disabled_ +Boot-Consoles-MemDump-6 | `mwc` | _Disabled_ +Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ +Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ +Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ + +Domain | `Config` name | `Value` +-------------------- | -------------- | -------------------------------------- +Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m +Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m +Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y +Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y +Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y +Kernel-General-MAC-6 | CONFIG_SECURITY | y +Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y +Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y + +Domain | `Config` name | `Value` +---------------------- | -------------- | ------- +Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` + +Domain | `Config` name | `Value` +--------------------------- | --------------- | ------- +Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` + +Domain | `Config` name | `Value` +------------------------------- | ----------------------- | ------- +Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` + +Domain | `Config` name | `Value` +---------------------------- | --------------- | ------- +Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` + +Domain | `Config` name | `Value` +--------------------------- | ------------------------------ | ------- +Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` + +Domain | `Config` name | `Value` +---------------------------- | ---------------------- | ------- +Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y` + +Domain | `Config` name | `Value` +-------------------------- | -------------------- | ------- +Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` +Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n` + +Domain | `Config` name | `Value` +------------------------ | ---------------- | ------- +Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` + +Domain | `Config` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` + +Domain | `Variable` name | `Value` +------------------------------ | ------------------------- | ------- +Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` + +Domain | Object | _State_ +------------------------ | ------------------- | ---------- +Kernel-General-Drivers-1 | `USB` | _Disabled_ +Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ +Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ + +Domain | `compiler` and `linker` options | _State_ +-------------------------------- | ------------------------------- | -------- +Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ + +Domain | `compiler` and `linker` options | _State_ +--------------------------------- | ------------------------------- | -------- +Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ +Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ + +Domain | Object | Recommendations +------------------------------- | --------------- | -------------------------------- +Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. + +Domain | `Config` name | `Value` +------------------------------ | ---------------- | ------- +Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` + +Domain | `Config` name | `Value` +------------------------ | ------------------- | ------- +Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` + +Domain | `Config` name | `Value` +-------------------- | ------------- | ------- +Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` +Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` + +Domain | `Config` name | `Value` +--------------------- | -------------------------- | ------- +Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n` + +Domain | `Config` name | `Value` +------------------------------ | --------------------- | ------- +Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` + +Domain | `compiler` and `linker` options | _State_ +----------------------------- | ------------------------------- | -------- +Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ + +Domain | `compiler` options and `config` name | `Value` +------------------------------- | ------------------------------------ | ------- +Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` +Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` + +Domain | `Config` name | `Value` +------------------------ | ---------------------------- | ------- +Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n` +Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n` +Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n` +Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n` + +Domain | `Config` name | `Value` +----------------------------- | ------------------------- | ----------------------------------- +Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y` +Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"` +Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y` + +Domain | `Config` name | `Value` +---------------------- | ------------- | ------- +Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` + +Domain | `Config` name | `Value` +----------------------- | -------------------- | ------- +Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` + +Domain | `Config` name | `Value` +------------------------------ | -------------------- | ------- +Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` + +Domain | `Config` name | `Value` +---------------------- | ------------------- | ------- +Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n` + +Domain | `Config` name | `Value` +---------------------- | ---------------- | ------- +Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` + +Domain | `Config` name | `Value` +---------------------- | --------------- | ------- +Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` + +Domain | `Config` name | `Value` +------------------------ | ------------------ | ------- +Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` +Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` + +Domain | `Config` name | `Value` +------------------------ | ------------------------- | ------- +Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` + +Domain | `Config` name | `Value` +------------------ | --------------------- | ------- +Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` +Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n` + +Domain | `Config` name | `Value` +------------------------- | ----------------- | ------- +Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` + +Domain | `Config` name | `Value` +------------------ | ------------- | ------- +Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` + +Domain | `Config` name | `Value` +------------------------ | ----------------- | ------- +Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` + +Domain | `File` name | `Value` +---------------------------- | -------------------------------- | ------- +Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` + +Domain | `File` or `Directorie` name | _State_ +---------------------------- | --------------------------- | ----------------------------- +Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ +Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ + +Domain | `File` name | `Value` +-------------------- | --------------------------------- | ------- +Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` + +Domain | `Config` name | `Value` +--------------------- | ----------------- | ------- +Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` + +Domain | `Config` name | `Value` +------------------------ | --------------- | ------- +Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` +Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` + +Domain | `Partition` | `Value` +-------------------------- | ------------------- | ----------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`. +Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. +Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. + +Domain | `Config` name | _State_ or `Value` +-------------------------- | ----------------------- | ----------------------------------------------------------------------- +Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. + +Domain | `Label` name | Recommendations +------------------ | ------------ | ----------------------------------------------------------- +Kernel-MAC-Floor-1 | `^` | Only for privileged system services. +Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC. + +Domain | `Label` name | Recommendations +------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute. +Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`. +Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege. +Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append. +Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem. + +Domain | `Label` name | Recommendations +------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- +Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode. +Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute. +Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user. + +Domain | Object | Recommendations +------------------ | -------------- | ------------------------------------ +Platform-SystemD-1 | Security model | Use Namespaces for containerization. +Platform-SystemD-2 | Security model | Use CGroups to organise processes. + +Domain | Object | Recommendations +--------------- | -------------- | ------------------------------------ +Platform-DBus-1 | Security model | Use D-Bus as IPC. +Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html) + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ------- +Platform-Utilities-1 | `connman` | _Used_ as a connection manager. +Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. +Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. +Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. + +Domain | Object | Recommendations +---------------------- | -------------- | -------------------------------- +Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. + +Domain | Object | Recommendations +----------------------- | ----------- | ------------------------------------- +Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. + +Domain | `Tool` name | _State_ +-------------------- | ----------- | ---------------------------------------------------------------------- +Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. + +Domain | `Utility` name and normal `path` | _State_ +--------------------- | ---------------------------------------------------- | ---------- +Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_ +Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_ +Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_ +Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_ +Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_ +Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_ +Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_ +Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_ +Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_ +Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_ +Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_ +Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_ +Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_ +Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_ +Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_ +Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_ +Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_ +Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_ +Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_ +Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_ +Platform-Utilities-22 | `SSH` | _Disabled_ +Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_ +Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_ +Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_ +Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_ +Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_ +Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_ +Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_ +Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_ +Platform-Utilities-31 | `awk` (busybox) | _Enabled_ +Platform-Utilities-32 | `cut` (busybox) | _Enabled_ +Platform-Utilities-33 | `df` (busybox) | _Enabled_ +Platform-Utilities-34 | `echo` (busybox) | _Enabled_ +Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_ +Platform-Utilities-36 | `grep` (busybox) | _Enabled_ +Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_ +Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_ +Platform-Utilities-39 | `printf` (busybox) | _Enabled_ +Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_ +Platform-Utilities-41 | `tail` (busybox) | _Enabled_ +Platform-Utilities-42 | `tee` (busybox) | _Enabled_ +Platform-Utilities-43 | `test` (busybox) | _Enabled_ + +Domain | Object | Recommendations +--------------------- | ---------------- | ----------------------------------------------------- +Platform-Users-root-1 | Main application | Should not execute as root. +Platform-Users-root-2 | UI | Should run in a context on a user with no capability. + +Domain | `Utility` name | _State_ +--------------------- | -------------- | ------------- +Platform-Users-root-3 | `login` | _Not allowed_ +Platform-Users-root-4 | `su` | _Not allowed_ +Platform-Users-root-5 | `ssh` | _Not allowed_ +Platform-Users-root-6 | `scp` | _Not allowed_ +Platform-Users-root-7 | `sftp` | _Not allowed_ + +Domain | Object | Recommendations +-------------------------- | --------- | ----------------------------------------------------------------------- +Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. +Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. + +Domain | Tech name | Recommendations +---------------------------------- | --------- | -------------------------------------------------------------------------- +Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. + +Domain | Tech name | Recommendations +----------------------------------------- | --------- | ---------------------------------------------------------------------- +Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices. +Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure. +Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. +Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. + +Domain | Object | Recommendations +----------------------- | ------ | ------------------------------------------------------------------ +Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. + +Domain | Tech name or object | Recommendations +---------------------------- | ------------------- | ------------------------------------------------------------------------- +Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled +Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used +Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing. +Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password. +Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update. + +Domain | Tech name | Recommendations +--------------------------------- | ------------- | ------------------------------------------------------------ +Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution. +Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring +Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model. +Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed. +Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks. + +Domain | Tech name | Recommendations +-------------------------------- | --------- | -------------------------- +Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid +Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. + +Domain | Tech name | Recommendations +----------------------------- | --------- | -------------------------------------------- +Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. + +Domain | Tech name | Recommendations +--------------------------- | --------- | ------------------------------------------------------ +Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. +Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. + +Domain | Object | Recommendations +---------------------------- | -------------- | -------------------------------------- +Application-Cloud-Download-1 | authentication | Must implement authentication process. +Application-Cloud-Download-2 | Authorization | Must implement Authorization process. + +Domain | Object | Recommendations +---------------------------------- | ------------- | ---------------------------------------------------------- +Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI. +Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection. +Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST. +Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS). +Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority. + +Domain | Object | Recommendations +----------------------------- | ----------------------------------------- | --------------------------------- +Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. + +# Todo notes + +Domain | Improvement +--------------- | ---------------------------------------------------- +Boot-Abstract-1 | More generic and add examples (The chain of trust). + +Domain | Improvement +--------------- | ------------------------------------------- +Boot-Abstract-1 | Review the definition of the "boot loader". + +Domain | Improvement +--------------- | ------------------------------------ +Boot-Consoles-1 | Secure loader: No reference earlier? + +Domain | Improvement +--------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- +Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). + +Domain | Improvement +-------------------------------- | ----------------------------- +Kernel-General-IndependentExec-1 | Kernel or/and platform part ? + +Domain | Improvement +------------------------------- | --------------- +Kernel-General-LibraryLinking-1 | Keep this part? + +Domain | Improvement +------------------- | -------------------------------- +Platform-Abstract-1 | Create a graphics and sound part. + +Domain | Improvement +------------------- | ----------- +Platform-Services-1 | SystemD ? +Platform-Services-2 | Secure daemon ? + +Domain | Improvement +----------------------------- | ------------------------ +Platform-Users-Capabilities-1 | Kernel or Platform-user? +Platform-Users-Capabilities-2 | Add config note. + +Domain | Improvement +-------------------------- | ------------------------------ +Application-Installation-1 | Talk about AppFw offline mode. + +Domain | Improvement +----------------------- | ---------------------------------------------------------- +Application-Signature-1 | Add content (see secure build in Secure development part). + +Domain | Improvement +---------------------- | ------------ +Application-Services-1 | Add content (Which services?). +Application-Services-2 | Add Binder. + +Domain | Improvement +----------------------- | ----------------- +Connectivity-Abstract-1 | Improve abstract. + +Domain | Improvement +----------------------- | ------------------------------------------- +Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). + +Domain | Improvement +------------- | ----------------- +Update-SOTA-1 | Part to complete. + +Domain | Improvement +----------------------- | ------------ +SecureDev-SecureBuild-1 | Add content. + +Domain | Improvement +---------------------- | ------------ +SecureDev-Signatures-1 | Add content. + +Domain | Improvement +--------------------- | ----------------------------------------------------- +SecureDev-CodeAudit-1 | Add CVE analyser. +SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). \ No newline at end of file diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png new file mode 100644 index 0000000..7b87c29 Binary files /dev/null and b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png differ diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png new file mode 100644 index 0000000..56a7c23 Binary files /dev/null and b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png differ diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png new file mode 100644 index 0000000..d984d1a Binary files /dev/null and b/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png differ -- cgit 1.2.3-korg