diff options
| author |   Shankho Boron Ghosh <shankhoghosh123@gmail.com> | 2020-11-18 19:55:02 +0530 |
|---|---|---|
| committer |   Jan-Simon Moeller <jsmoeller@linuxfoundation.org> | 2020-11-18 16:51:07 +0000 |
| commit | 9cc56459419f1225f5e9851825ad305424b3d6fb (patch) | |
| tree | 6b761ad38074084217472fd47f23fd8c61eb3de1 /docs | |
| parent | c04ab11b946684902e3e39aef475a2d16c09e1c4 (diff) | |
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 <shankhoghosh123@gmail.com>
Change-Id: I1ab478348a05464612d67f0e8a4570bda309022d
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25586
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Diffstat (limited to 'docs')
48 files changed, 2824 insertions, 3096 deletions
diff --git a/docs/2_Architecture_Guides/0_Build_Process.md b/docs/2_Architecture_Guides/1_Introduction/0_Build_Process.md index dba54c3..7137deb 100644 --- a/docs/2_Architecture_Guides/0_Build_Process.md +++ b/docs/2_Architecture_Guides/1_Introduction/0_Build_Process.md @@ -1,5 +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/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.pdf b/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf Binary files differindex c5be950..c5be950 100644 --- a/docs/2_Architecture_Guides/2.1_AGL_Requirements_Specifications/AGL Requirements Specifications.pdf +++ b/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf 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.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.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 -<!-- section-todo --> - -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). - -<!-- end-section-todo --> 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 - -<!-- section-todo --> - -Domain | Improvement ---------------- | ---------------------------------------------------- -Boot-Abstract-1 | More generic and add examples (The chain of trust). - -<!-- end-section-todo --> - -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. - -<!-- section-todo --> - -Domain | Improvement ---------------- | ------------------------------------------- -Boot-Abstract-1 | Review the definition of the "boot loader". - -<!-- end-section-todo --> - -**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_. - -<!-- section-config --> - -Domain | _Variable_ / `Config` name | `Value` ----------------------- | -------------------------- | ------- -Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2` -Boot-Image-Selection-2 | _bootdelay_ | `-2` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -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_ - -<!-- end-section-config --> 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. - -<!-- section-config --> - -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_ - -<!-- end-section-config --> <!-- section-config --> - -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_ - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## Disable all unused Network Interfaces - -Only used network interfaces should be enabled. Where possible, services should -also be limited to those necessary. - -<!-- section-config --> - -Domain | Communication modes | _State_ --------------------- | -------------------- | --------------------------------------------------------------------------------------------- -Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used. - -<!-- end-section-config --> - -## Remove or Disable Unnecessary Services, Ports, and Devices - -Restrict the `services`, `ports` and `devices` to those used. - -<!-- section-config --> - -Domain | Object | Recommendations --------------------- | --------------------------------- | ------------------------------------------------------------- -Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used. - -<!-- end-section-config --> - -## 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. - -<!-- section-config --> - -Domain | `Command` name | _State_ --------------------------- | -------------- | --------- -Boot-Communication-Flash-1 | `do_nand` | _Disable_ - -<!-- end-section-config --> - -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: - -<!-- section-config --> - -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` - -<!-- end-section-config --> <!-- section-todo --> - -Domain | Improvement ---------------- | ------------------------------------ -Boot-Consoles-1 | Secure loader: No reference earlier? - -<!-- end-section-todo --> - -And set "**silent**" environment variable. For the Secure loader, -disable the traces by not defining the below macro: - -<!-- section-config --> - -Domain | `Environment variable` name | _State_ ----------------------- | --------------------------- | ------------- -Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_ - -<!-- end-section-config --> - -For sboot proper configuration needs to be done to disable the serial console. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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: - -<!-- section-config --> - -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` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## (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. -``` - -<!-- section-config --> - -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_ - -<!-- end-section-config --> - -Similarly, memory dump support shall be disabled from sboot. 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. - -<!-- section-config --> - -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 - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------- | -------------- | ------- -Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` - -<!-- end-section-config --> - -<!-- section-note --> - -**kexec** can load arbitrary kernels but signing of new kernel can be enforced -like it is can be enforced for new modules. - -<!-- end-section-note --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ---------------------------- | --------------- | ------- -Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## Disable Sysctl syscall support - -Enabling this will result in code being included that is hard to maintain and -not well tested. - -<!-- section-config --> - -Domain | `Config` name | `Value` -------------------------------- | ----------------------- | ------- -Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------------- | --------------- | ------- -Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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**. - -<!-- section-config --> - -Domain | `Config` name | `Value` ---------------------------- | ------------------------------ | ------- -Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` - -<!-- end-section-config --> - -<!-- section-note --> - -It doesn't strictly need to be `setuid`, there is an option of shipping firmware -builtin into kernel without initrd/filesystem. - -<!-- end-section-note --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------------- | ---------------------- | ------- -Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` --------------------------- | -------------------- | ------- -Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n` -Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------- | ---------------- | ------- -Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` - -<!-- end-section-config --> - -It is also possible to block the loading of modules after startup with -"kernel.modules_disabled". - -<!-- section-config --> - -Domain | `Variable` name | `Value` ------------------------------- | ------------------------- | ------- -Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | Object | _State_ ------------------------- | ------------------- | ---------- -Kernel-General-Drivers-1 | `USB` | _Disabled_ -Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ -Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## Position Independent Executables - -<!-- section-todo --> - -Domain | Improvement --------------------------------- | ----------------------------- -Kernel-General-IndependentExec-1 | Kernel or/and platform part ? - -<!-- end-section-todo --> - -<!-- section-config --> - -Domain | `compiler` and `linker` options | _State_ --------------------------------- | ------------------------------- | -------- -Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -Domain | `compiler` and `linker` options | _State_ ---------------------------------- | ------------------------------- | -------- -Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_ -Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_ - -<!-- end-section-config --> - -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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## Library linking - -<!-- section-todo --> - -Domain | Improvement -------------------------------- | --------------- -Kernel-General-LibraryLinking-1 | Keep this part? - -<!-- end-section-todo --> - -It is recommended that dynamic linking should generally not be allowed. This -will avoid the user from replacing a library with malicious library. - -<!-- section-config --> - -Domain | Object | Recommendations -------------------------------- | --------------- | -------------------------------- -Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed. - -<!-- end-section-config --> - -<!-- section-note --> - -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. - -<!-- end-section-note --> 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: - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------------- | ---------------- | ------- -Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n` - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------- | ------------------- | ------- -Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` --------------------- | ------------- | ------- -Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n` - -<!-- end-section-config --> - -<!-- section-note --> - -- 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. - -<!-- end-section-note --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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; - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n` -Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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**. - -<!-- section-config --> - -Domain | `Config` name | `Value` ---------------------- | -------------------------- | ------- -Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y` - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------------- | --------------------- | ------- -Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## Stack Smashing Attacks - -<!-- section-config --> - -Domain | `compiler` and `linker` options | _State_ ------------------------------ | ------------------------------- | -------- -Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_ - -<!-- end-section-config --> - -Emit extra code to check for buffer overflows, such as stack smashing attacks. - --------------------------------------------------------------------------------- - -## Detect Buffer Overflows - -<!-- section-config --> - -Domain | `compiler` options and `config` name | `Value` -------------------------------- | ------------------------------------ | ------- -Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` -Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y` - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -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` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -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` - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------- | ------------- | ------- -Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------ | -------------------- | ------- -Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------------- | -------------------- | ------- -Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` - -<!-- end-section-config --> 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------- | ------------------- | ------- -Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n` - -<!-- end-section-config --> - -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. - -<!-- section-note --> - -At least `CONFIG_DEBUG_INFO_REDUCED` should be always enabled for developers to -convert addresses in oops messages to line numbers. - -<!-- end-section-note --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------- | ---------------- | ------- -Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## Disable Tracing - -FTrace enables the kernel to trace every kernel function. Providing kernel trace -functionality would assist an attacker in discovering attack vectors. - -<!-- section-config --> - -Domain | `Config` name | `Value` ----------------------- | --------------- | ------- -Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------- | ------------------ | ------- -Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n` -Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------- | ------------------------- | ------- -Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------- | --------------------- | ------- -Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n` -Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n` - -<!-- end-section-config --> - -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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` -------------------------- | ----------------- | ------- -Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------- | ------------- | ------- -Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------- | ----------------- | ------- -Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | `File` name | `Value` ----------------------------- | -------------------------------- | ------- -Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1` - -<!-- end-section-config --> - -Additionally, various files and directories should be readable only by the root -user: `/boot/vmlinuz*`, `/boot/System.map*`, `/sys/kernel/debug/`, -`/proc/slabinfo` - -<!-- section-config --> - -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_ - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | `File` name | `Value` --------------------- | --------------------------------- | ------- -Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1` - -<!-- end-section-config --> - -Enable the below compiler and linker options when building user-space -applications to avoid stack smashing, buffer overflow attacks. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ---------------------- | ----------------- | ------- -Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` - -<!-- end-section-config --> 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. - -<!-- section-config --> - -Domain | `Config` name | `Value` ------------------------- | --------------- | ------- -Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n` -Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n` - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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: - -<!-- section-config --> - -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`. - -<!-- end-section-config --> <!-- section-note --> - -If `CONFIG_DEVTMPFS_MOUNT` is set, then the kernel will mount /dev and will not -apply the `nosuid`, `noexec` options. Either disable `CONFIG_DEVTMPFS_MOUNT` or -add a remount with `noexec` and `nosuid` options to system startup. - -<!-- end-section-note --> <!-- section-config --> - -Domain | `Config` name | _State_ or `Value` --------------------------- | ----------------------- | ----------------------------------------------------------------------- -Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. - -<!-- end-section-config --> 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). - -<!-- section-todo --> - -Domain | Improvement -------------------- | -------------------------------- -Platform-Abstract-1 | Create a graphics and sound part. - -<!-- end-section-todo --> - -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). - -<!-- section-note --> - -The tools and concepts used to meet these needs are only examples. Any other -tool that meets the need can be used. - -<!-- end-section-note --> - -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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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 - -<!-- section-note --> - -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). - -<!-- end-section-note --> - -**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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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 - -<!-- section-note --> - -- 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. - -<!-- end-section-note --> <!-- section-config --> - -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. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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 - -<!-- section-config --> - -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. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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 - -<!-- section-config --> - -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. - -<!-- end-section-config --> - -## 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). - -<!-- section-config --> - -Domain | Object | Recommendations ------------------- | -------------- | ------------------------------------ -Platform-SystemD-1 | Security model | Use Namespaces for containerization. -Platform-SystemD-2 | Security model | Use CGroups to organise processes. - -<!-- end-section-config --> - -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. - -<!-- pagebreak --> - -## 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. - - -<!-- section-config --> - -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) - -<!-- end-section-config --> 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 - -<!-- section-todo --> - -Domain | Improvement -------------------- | ----------- -Platform-Services-1 | SystemD ? -Platform-Services-2 | Secure daemon ? - -<!-- end-section-todo --> - -## 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> 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. - -<!-- section-note --> - -- The **security model** refers to the security model used to ensure security - and to the tools that are provided for implementing that model. It's an - implementation detail that should not impact the layers above the application - framework. - -- The **security model** refers to how **DAC** (**D**iscretionary **A**ccess - **C**ontrol), **MAC** (Mandatory Access Control) and `Capabilities` are used - by the system to ensure security and privacy. It also includes features of - reporting using audit features and by managing logs and alerts. - -<!-- end-section-note --> - -The **AppFw** uses the security model to ensure the security and the privacy of -the applications that it manages. It must be compliant with the underlying -security model. But it should hide it to the applications. - -<!-- section-config --> - -Domain | Object | Recommendations ----------------------- | -------------- | -------------------------------- -Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model. - -<!-- end-section-config --> - -See [AGL AppFw Privileges -Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) -and [AGL - Application Framework -Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) -for more information. - -<!-- pagebreak --> - -The Security Manager communicates policy information to **Cynara**, which -retains information in its own database in the format of a text file with -comma-separated values (CSV). There are provisions to retain a copy of the CSV -text file when the file is being updated. - -Runtime checking occurs through **Cynara**. Each application that is added to -the framework has its own instantiation of a SMACK context and D-bus bindings. -The afb_daemon and Binder form a web-service that is communicated to through -http or a websocket from the application-proper. This http or websocket -interface uses a standard unique web token for API communication. - - - -## Cynara - -There's a need for another mechanism responsible for checking applicative -permissions: Currently in AGL, this task depends on a policy-checker service -(**Cynara**). - -- Stores complex policies in databases. -- "Soft" security (access is checked by the framework). - -Cynara interact with **D-Bus** in order to deliver this information. - -Cynara consists of several parts: - -- Cynara: a daemon for controlling policies and responding to access control - requests. -- Database: a spot to hold policies. -- Libraries: several static and dynamic libraries for communicating with Cynara. - -The daemon communicates to the libraries over Unix domain sockets. The database -storage format is a series of CSV-like files with an index file. - -There are several ways that an attacker can manipulate policies of the Cynara -system: - -- Disable Cynara by killing the process. -- Tamper with the Cynara binary on-disk or in-memory. -- Corrupt the database controlled by Cynara. -- Tamper with the database controlled by Cynara. -- Highjack the communication between Cynara and the database. - -The text-based database is the weakest part of the system and although there are -some consistency mechanisms in place (i.e. the backup guard), these mechanisms -are weak at best and can be countered by an attacker very easily. - -<!-- section-config --> - -Domain | Object | Recommendations ------------------------ | ----------- | ------------------------------------- -Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. - -<!-- end-section-config --> - -### Policies - -- Policy rules: - - - Are simple - for pair [application context, privilege] there is straight - answer (single Policy Type): [ALLOW / DENY / ...]. - - No code is executed (no script). - - Can be easily cached and managed. - -- Application context (describes id of the user and the application credentials) - It is build of: - - - UID of the user that runs the application. - - **SMACK** label of application. - -## Holding policies - -Policies are kept in buckets. Buckets are set of policies which have additional -a property of default answer, the default answer is yielded if no policy matches -searched key. Buckets have names which might be used in policies (for -directions). - -## Attack Vectors - -The following attack vectors are not completely independent. While attackers may -have varying levels of access to an AGL system, experience has shown that a -typical attack can start with direct access to a system, find the -vulnerabilities, then proceed to automate the attack such that it can be invoked -from less accessible standpoint (e.g. remotely). Therefore, it is important to -assess all threat levels, and protect the system appropriately understanding -that direct access attacks are the door-way into remote attacks. - -### Remote Attacks - -The local web server interface used for applications is the first point of -attack, as web service APIs are well understood and easily intercepted. The -local web server could potentially be exploited by redirecting web requests -through the local service and exploiting the APIs. While there is the use of a -security token on the web service API, this is weak textual matching at best. -This will not be difficult to spoof. It is well known that [API Keys do not -provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/). - -It is likely that the architectural inclusion of an http / web-service interface -provided the most flexibility for applications to be written natively or in -HTML5. However, this flexibility may trade-off with security concerns. For -example, if a native application were linked directly to the underlying -framework services, there would be fewer concerns over remote attacks coming -through the web-service interface. - -Leaving the interface as designed, mitigations to attacks could include further -securing the interface layer with cryptographic protocols: e.g. encrypted -information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman). - -### User-level Native Attacks - -- Modifying the CSV data-base -- Modifying the SQLite DB -- Tampering with the user-level binaries -- Tampering with the user daemons -- Spoofing the D-bus Interface -- Adding executables/libraries - -With direct access to the device, there are many security concerns on the native -level. For example, as **Cynara** uses a text file data-base with -comma-separated values (CSV), an attacker could simply modify the data-base to -escalate privileges of an application. Once a single application has all the -privileges possible on the system, exploits can come through in this manner. -Similarly the SQLite database used by the Security Manager is not much different -than a simple text file. There are many tools available to add, remove, modify -entries in an SQLite data-base. - -On the next level, a common point of attack is to modify binaries or daemons for -exploiting functionality. There are many Linux tools available to aid in this -regard, including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml), -and [radare2](https://rada.re/r/). With the ability to modify binaries, an -attacker can do any number of activities including: removing calls to security -checks, redirecting control to bypass verification functionality, ignoring -security policy handling, escalating privileges, etc. - -Additionally, another attack vector would be to spoof the D-bus interface. D-bus -is a message passing system built upon Inter-Process Communication (IPC), where -structured messages are passed based upon a protocol. The interface is generic -and well documented. Therefore, modifying or adding binaries/libraries to spoof -this interface is a relatively straight-forward process. Once the interface has -been spoofed, the attacker can issue any number of commands that lead into -control of low-level functionality. - -Protecting a system from native attacks requires a methodical approach. First, -the system should reject processes that are not sanctioned to run. -Signature-level verification at installation time will help in this regard, but -run-time integrity verification is much better. Signatures need to originate -from authorized parties, which is discussed further in a later section on the -Application Store. - -On the next level, executables should not be allowed to do things where they -have not been granted permission. DAC and SMACK policies can help in this -regard. On the other hand, there remain concerns with memory accesses, system -calls, and other process activity that may go undetected. For this reason, a -secure environment which monitors all activity can give indication of all -unauthorized activity on the system. - -Finally, it is very difficult to catch attacks of direct tampering in a system. -These types of attacks require a defense-in-depth approach, where complementary -software protection and hardening techniques are needed. Tamper-resistance and -anti-reverse-engineering technologies include program -transformations/obfuscation, integrity verification, and white-box cryptography. -If applied in a mutually-dependent fashion and considering performance/security -tradeoffs, the approach can provide an effective barrier to direct attacks to -the system. Furthermore, the use of threat monitoring provides a valuable -telemetry/analytics capability and the ability to react and renew a system under -attack. - -### Root-level Native Attacks - -- Tampering the system daemon -- Tampering Cynara -- Tampering the security manager -- Disabling SMACK -- Tampering the kernel - -Once root-level access (i.e. su) has been achieved on the device, there are many -ways to compromise the system. The system daemon, **Cynara**, and the security -manager are vulnerable to tampering attacks. For example, an executable can be -modified in memory to jam a branch, jump to an address, or disregard a check. -This can be as simple as replacing a branch instruction with a NOP, changing a -memory value, or using a debugger (e.g. gdb, IDA) to change an instruction. -Tampering these executables would mean that policies can be ignored and -verification checks can be bypassed. - -Without going so far as to tamper an executable, the **SMACK** system is also -vulnerable to attack. For example, if the kernel is stopped and restarted with -the *security=none* flag, then SMACK is not enabled. Furthermore, `systemd` -starts the loading of **SMACK** rules during start-up. If this start-up process -is interfered with, then **SMACK** will not run. Alternatively, new policies can -be added with `smackload` allowing unforseen privileges to alternative -applications/executables. - -Another intrusion on the kernel level is to rebuild the kernel (as it is -open-source) and replace it with a copy that has **SMACK** disabled, or even -just the **SMACK** filesystem (`smackfs`) disabled. Without the extended label -attributes, the **SMACK** system is disabled. - -Root-level access to the device has ultimate power, where the entire system can -be compromised. More so, a system with this level access allows an attacker to -craft a simpler *point-attack* which can operate on a level requiring fewer -privileges (e.g. remote access, user-level access). - -## Vulnerable Resources - -### Resource: `afm-user-daemon` - -The `afm-user-daemon` is in charge of handling applications on behalf of a user. -Its main tasks are: - -- Enumerate applications that the end user can run and keep this list available - on demand. -- Start applications on behalf of the end user, set user running environment, - set user security context. -- List current runnable or running applications. -- Stop (aka pause), continue (aka resume), terminate a running instance of a - given application. -- Transfer requests for installation/uninstallation of applications to the - corresponding system daemon afm-system-daemon. - -The `afm-user-daemon` launches applications. It builds a secure environment for -the application before starting it within that environment. Different kinds of -applications can be launched, based on a configuration file that describes how -to launch an application of a given kind within a given launching mode: local or -remote. Launching an application locally means that the application and its -binder are launched together. Launching an application remotely translates in -only launching the application binder. - -The UI by itself has to be activated remotely by a request (i.e. HTML5 -homescreen in a browser). Once launched, running instances of the application -receive a `runid` that identifies them. `afm-user-daemon` manages the list of -applications that it has launched. When owning the right permissions, a client -can get the list of running instances and details about a specific running -instance. It can also terminate, stop or continue a given application. If the -client owns the right permissions, `afm-user-daemon` delegates the task of -installing and uninstalling applications to `afm-system-daemon`. - -`afm-user-daemon` is launched as a `systemd` service attached to a user session. -Normally, the service file is located at -/usr/lib/systemd/user/afm-user-daemon.service. - -Attacker goals: - -- Disable `afm-user-daemon`. -- Tamper with the `afm-user-daemon` configuration. - - /usr/lib/systemd/user/afm-user-daemon.service. - - Application(widget) config.xml file. - - /etc/afm/afm-launch.conf (launcher configuration). - -- Escalate user privileges to gain more access with `afm-user-daemon`. -- Install malicious application (widget). -- Tamper with `afm-user-daemon` on disk or in memory. - -### Resource: `afm-system-daemon` - -The `afm-system-daemon` is in charge of installing applications on the AGL -system. Its main tasks are: - -- Install applications and setup security framework for newly installed - applications. -- Uninstall applications. - -`afm-system-daemon` is launched as a `systemd` service attached to system. -Normally, the service file is located at -/lib/systemd/system/afm-systemdaemon.service. - -Attacker goals: - -- Disable `afm-system-daemon`. -- Tamper with the `afm-system-daemon` configuration. -- Tamper `afm-system-daemon` on disk or in memory. - -### Resource `afb-daemon` - -`afb-binder` is in charge of serving resources and features through an HTTP -interface. `afb-daemon` is in charge of binding one instance of an application -to the AGL framework and AGL system. The application and its companion binder -run in a secured and isolated environment set for them. Applications are -intended to access to AGL system through the binder. `afb-daemon` binders serve -files through HTTP protocol and offers developers the capability to expose -application API methods through HTTP or WebSocket protocol. - -Binder bindings are used to add APIs to `afb-daemon`. The user can write a -binding for `afb-daemon`. The binder `afb-daemon` serves multiple purposes: - -1. It acts as a gateway for the application to access the system. -2. It acts as an HTTP server for serving files to HTML5 applications. -3. It allows HTML5 applications to have native extensions subject to security - enforcement for accessing hardware resources or for speeding up parts of - algorithm. - -Attacker goals: - -- Break from isolation. -- Disable `afb-daemon`. -- Tamper `afb-demon` on disk or in memory. -- Tamper **capabilities** by creating/installing custom bindings for - `afb-daemon`.
\ No newline at end of file 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. - -<!-- section-config --> - -Domain | `Tool` name | _State_ --------------------- | ----------- | ---------------------------------------------------------------------- -Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools. - -<!-- end-section-config --> - -## 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. - -<!-- section-config --> - -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_ - -<!-- end-section-config --> <!-- section-note --> - -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. - -<!-- end-section-note --> 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> - -Root access should not be allowed for the following utilities: - -<!-- section-config --> - -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_ - -<!-- end-section-config --> - -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`. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## Capabilities - -<!-- section-todo --> - -Domain | Improvement ------------------------------ | ------------------------ -Platform-Users-Capabilities-1 | Kernel or Platform-user? -Platform-Users-Capabilities-2 | Add config note. - -<!-- end-section-todo --> - -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/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 - -<!-- section-todo --> - -Domain | Improvement --------------------------- | ------------------------------ -Application-Installation-1 | Talk about AppFw offline mode. - -<!-- end-section-todo --> - -## 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. - -<!-- section-note --> - -During early release, default Apps are installed on the image at first boot. - -<!-- end-section-note --> - -<!-- section-config --> - -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. - -<!-- end-section-config --> 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 - -<!-- section-todo --> - -Domain | Improvement ------------------------ | ---------------------------------------------------------- -Application-Signature-1 | Add content (see secure build in Secure development part). - -<!-- end-section-todo --> 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 - -<!-- section-todo --> - -Domain | Improvement ----------------------- | ------------ -Application-Services-1 | Add content (Which services?). -Application-Services-2 | Add Binder. - -<!-- end-section-todo --> 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. - -<!-- section-todo --> - -Domain | Improvement ------------------------ | ----------------- -Connectivity-Abstract-1 | Improve abstract. - -<!-- end-section-todo --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | Tech name | Recommendations ----------------------------------- | --------- | -------------------------------------------------------------------------- -Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> 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. - -<!-- section-config --> - -Domain | Object | Recommendations ------------------------ | ------ | ------------------------------------------------------------------ -Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. - -<!-- end-section-config --> - -We will see the following parts: - -- [Wifi](#wifi) - -- [Bluetooth](#bluetooth) - -- [Cellular](#cellular) - -- [Radio](#radio) - -- [NFC](#nfc) - -<!-- section-todo --> - -Domain | Improvement ------------------------ | ------------------------------------------- -Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). - -<!-- end-section-todo --> - --------------------------------------------------------------------------------- - -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) - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> - -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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> - -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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | Tech name | Recommendations --------------------------------- | --------- | -------------------------- -Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid -Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -Domain | Tech name | Recommendations ------------------------------ | --------- | -------------------------------------------- -Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> 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. - -<!-- section-config --> - -Domain | Object | Recommendations ----------------------------- | -------------- | -------------------------------------- -Application-Cloud-Download-1 | authentication | Must implement authentication process. -Application-Cloud-Download-2 | Authorization | Must implement Authorization process. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- pagebreak --> - -<!-- section-config --> - -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. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | Object | Recommendations ------------------------------ | ----------------------------------------- | --------------------------------- -Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. - -<!-- end-section-config --> 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 <machine> agl-sota <other-features...> -``` - -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). - -<!-- section-todo --> - -Domain | Improvement -------------- | ----------------- -Update-SOTA-1 | Part to complete. - -<!-- end-section-todo --> diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/Introduction.md b/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md index b4ccf37..ee5e7f7 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/Introduction.md +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md @@ -1,9 +1,7 @@ --- -title: Introduction +title: Overview --- -# 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 @@ -39,25 +37,6 @@ _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: - -<!-- section-config --> - -- The _config_ tag quickly identifies the configurations and the recommendations - to take. - -<!-- end-section-config --><!-- section-note --> - -- The _note_ tag allows you to notify some additional details. - -<!-- end-section-note --><!-- section-todo --> - -- The _todo_ tag shows the possible improvements. - -<!-- end-section-todo --> - -In annexes of this document, you can find all the _config_ and _todo_ notes. - ## Adversaries Adversaries and attackers within the Automotive space. @@ -184,14 +163,12 @@ 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. -<!-- pagebreak --> - ## AGL security overview AGL roots are based on security concepts. Those concepts are implemented by the security framework as shown in this picture: - + -------------------------------------------------------------------------------- @@ -206,8 +183,6 @@ The following table lists the strongest terms utilized within all this document. -------------------------------------------------------------------------------- -<!-- pagebreak --> - # References - [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html). diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/1_Hardware/Abstract.md b/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md index 7fe806f..328dd15 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/1_Hardware/Abstract.md +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md @@ -1,11 +1,7 @@ --- -title: Introduction +title: Hardware --- -# 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: @@ -41,42 +37,28 @@ 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. -<!-- section-config --> - 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. -<!-- end-section-config --> - -------------------------------------------------------------------------------- -<!-- pagebreak --> - ## Certificates -<!-- section-config --> - 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. -<!-- end-section-config --> - -------------------------------------------------------------------------------- ## Memory -<!-- section-config --> - 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. - -<!-- end-section-config --> +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.2_Security_Blueprint/3_Hypervisor/Abstract.md b/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md index 7cc3017..61cc227 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/3_Hypervisor/Abstract.md +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md @@ -1,23 +1,17 @@ --- -title: Introduction +title: Hypervisor --- -# Part 3 - Hypervisor - -Definition: "A hypervisor or virtual machine monitor (VMM) is computer software, -firmware or hardware that creates and runs virtual machines". +**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). -<!-- section-todo --> - 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)). -<!-- end-section-todo --> - ## 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. +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. + + + +## 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.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md b/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md index 2925efb..c08d06e 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md @@ -1,11 +1,7 @@ --- -title: Introduction +title: Application --- -# 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. @@ -55,7 +51,7 @@ distributor, and platform level store distributor. AGL may define a different number of third parties, but at a minimum an author and store distributor should be defined. - + Once the number of signatures has been established, verification of those signatures needs to be done at a minimum at installation time on the AGL device. @@ -87,3 +83,43 @@ _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.2_Security_Blueprint/8_Update_(Over_The_Air)/1.2.8.0_Abstract.md b/docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md index cd47ed0..60ae8e4 100644 --- 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_Security_Blueprint/8_Update_OTA.md @@ -1,11 +1,7 @@ --- -title: Introduction +title: Update (Over The Air) --- -# 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 @@ -92,3 +88,67 @@ _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 <machine> agl-sota <other-features...> +``` + +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.2_Security_Blueprint/9_Secure_development/1.2.9.0_Abstract.md b/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md index bfceefe..9cbe3b4 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/9_Secure_development/1.2.9.0_Abstract.md +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md @@ -1,9 +1,7 @@ --- -title: Introduction +title: Secure development --- -# Part 9 - Secure development - In order to save a lot of time in code auditing, developers must follow coding guidelines. @@ -17,24 +15,16 @@ Tools like: - [Kernel Drivers test](https://github.com/ucsb-seclab/dr_checker) with [docs](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pdf). -<!-- section-todo --> - Domain | Improvement ----------------------- | ------------ SecureDev-SecureBuild-1 | Add content. -<!-- end-section-todo --> - ## App/Widget signatures -<!-- section-todo --> - Domain | Improvement ---------------------- | ------------ SecureDev-Signatures-1 | Add content. -<!-- end-section-todo --> - ## Code audit These tools are used to check the correct implementation of functionalities and @@ -42,15 +32,11 @@ compliance with related good practices. - [Continuous Code Quality](https://www.sonarqube.org/). -<!-- section-todo --> - Domain | Improvement --------------------- | ----------------------------------------------------- SecureDev-CodeAudit-1 | Add CVE analyser. SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). -<!-- end-section-todo --> - ### SATS - [RATS](https://github.com/andrew-d/rough-auditing-tool-for-security) (Maybe to @@ -69,4 +55,4 @@ are depreciated and recognized as unsecured or cause problems. ### DATS - [wiki - list](https://en.wikipedia.org/wiki/Dynamic_program_analysis#Example_tools). + 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.2_Security_Blueprint/10_Annexes/1.2.10.1_Config_Notes.md b/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md index 293b6f3..c279203 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/10_Annexes/1.2.10.1_Config_Notes.md +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md @@ -1,9 +1,22 @@ --- -title: Config notes +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 -<!-- section-config --> + Domain | Object | Recommendations -------------------- | ---------- | ---------------------------------- @@ -486,4 +499,80 @@ Domain | Object | Reco ----------------------------- | ----------------------------------------- | --------------------------------- Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. -<!-- end-section-config --> +# 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.2_Security_Blueprint/5_Platform/App-flow.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png Binary files differindex 7b87c29..7b87c29 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/App-flow.png +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/App_signing_flow.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png Binary files differindex 56a7c23..56a7c23 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/App_signing_flow.png +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/WhiteBoxArchi.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png Binary files differindex d984d1a..d984d1a 100644 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/0_Introduction/WhiteBoxArchi.png +++ b/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png |
