From 981e9b9c4a40e248733d45cfedc6a512bdf95f5e Mon Sep 17 00:00:00 2001 From: mudcam Date: Thu, 7 Dec 2017 10:31:22 +0100 Subject: Add proposal for new security blueprint --- security-blueprint/part-7/3-Cloud.md | 107 +++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 security-blueprint/part-7/3-Cloud.md (limited to 'security-blueprint/part-7/3-Cloud.md') diff --git a/security-blueprint/part-7/3-Cloud.md b/security-blueprint/part-7/3-Cloud.md new file mode 100644 index 0000000..4d37ff4 --- /dev/null +++ b/security-blueprint/part-7/3-Cloud.md @@ -0,0 +1,107 @@ +# 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. + + -- cgit 1.2.3-korg From df4bdd6e9e5669451e7f60ecdc5c9e0d25e3f726 Mon Sep 17 00:00:00 2001 From: Sebastien Douheret Date: Fri, 8 Dec 2017 17:40:04 +0100 Subject: Added templating for section-xxx tags. Security Blueprint doc uses specific tags to display arrays (see docs/security-blueprint/README.md) Signed-off-by: Sebastien Douheret --- security-blueprint/README.md | 8 ++-- security-blueprint/annexes/ConfigNotes.md | 4 +- security-blueprint/annexes/todo.md | 8 ++-- security-blueprint/annexes/todoNotes.md | 4 +- security-blueprint/part-1/0_Abstract.md | 12 ++--- security-blueprint/part-2/0_Abstract.md | 8 ++-- security-blueprint/part-2/1-Image.md | 8 ++-- security-blueprint/part-2/2-Communication-modes.md | 18 +++---- security-blueprint/part-2/3-Consoles.md | 18 +++---- security-blueprint/part-3/0_Abstract.md | 4 +- security-blueprint/part-4/1-General.md | 56 +++++++++++----------- security-blueprint/part-4/2-Memory.md | 36 +++++++------- security-blueprint/part-4/3-Consoles.md | 20 ++++---- security-blueprint/part-4/4-Debug.md | 52 ++++++++++---------- security-blueprint/part-4/5-FileSystems.md | 12 ++--- security-blueprint/part-5/0_Abstract.md | 4 +- security-blueprint/part-5/1-MAC.md | 18 +++---- security-blueprint/part-5/2-SystemD.md | 4 +- security-blueprint/part-5/3-SystemBus.md | 4 +- security-blueprint/part-5/4-Services.md | 8 ++-- security-blueprint/part-5/5-AppFw.md | 12 ++--- security-blueprint/part-5/6-Utilities.md | 10 ++-- security-blueprint/part-5/7-Users.md | 12 ++--- security-blueprint/part-6/1-Installation.md | 12 ++--- security-blueprint/part-6/3-Signature.md | 4 +- security-blueprint/part-6/4-Services.md | 4 +- security-blueprint/part-7/0_Abstract.md | 4 +- security-blueprint/part-7/1-BusAndConnectors.md | 8 ++-- security-blueprint/part-7/2-Wireless.md | 28 +++++------ security-blueprint/part-7/3-Cloud.md | 12 ++--- security-blueprint/part-8/1-FOTA.md | 4 +- security-blueprint/part-8/2-SOTA.md | 4 +- security-blueprint/part-9/0_Abstract.md | 12 ++--- 33 files changed, 216 insertions(+), 216 deletions(-) (limited to 'security-blueprint/part-7/3-Cloud.md') diff --git a/security-blueprint/README.md b/security-blueprint/README.md index a56e3fd..d15e44f 100644 --- a/security-blueprint/README.md +++ b/security-blueprint/README.md @@ -10,19 +10,19 @@ We will cover topics starting from the lowest level (_Hardware_) up to the highe The document is filled with tags to easily identify important points: - + - The _config_ tag quickly identifies the configurations and the recommendations to take. - + - The _note_ tag allows you to notify some additional details. - + - The _todo_ tag shows the possible improvements. - + In annexes of this document, you can find all the _config_ and _todo_ notes. diff --git a/security-blueprint/annexes/ConfigNotes.md b/security-blueprint/annexes/ConfigNotes.md index 3e1f295..05b7228 100644 --- a/security-blueprint/annexes/ConfigNotes.md +++ b/security-blueprint/annexes/ConfigNotes.md @@ -1,5 +1,5 @@ # Config notes - + Domain | Object | Recommendations -------------------- | ---------- | ---------------------------------- @@ -474,4 +474,4 @@ Domain | Object | Recommendations ------------- | ----------------------------------------- | --------------- Update-FOTA-1 | Integrity, confidentiality and legitimacy | Must be secure. - + diff --git a/security-blueprint/annexes/todo.md b/security-blueprint/annexes/todo.md index c8fb035..91e39e3 100644 --- a/security-blueprint/annexes/todo.md +++ b/security-blueprint/annexes/todo.md @@ -8,20 +8,20 @@ ## Important - + - Add pointers to the doc throughout the document. - Change cover title. - + ## Less important - + - Merge All todo notes and this page. - Order sub-chapters like chapters. - Use notes like "¹, ² or ³"? - Change pdf generated part number. - + diff --git a/security-blueprint/annexes/todoNotes.md b/security-blueprint/annexes/todoNotes.md index e5f6377..077fd57 100644 --- a/security-blueprint/annexes/todoNotes.md +++ b/security-blueprint/annexes/todoNotes.md @@ -1,5 +1,5 @@ # Todo notes - + Domain | Improvement --------------- | ---------------------------------------------------- @@ -65,4 +65,4 @@ Domain | Improvement SecureDev-CodeAudit-1 | Add CVE analyser. SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). - + diff --git a/security-blueprint/part-1/0_Abstract.md b/security-blueprint/part-1/0_Abstract.md index 188c911..5664890 100644 --- a/security-blueprint/part-1/0_Abstract.md +++ b/security-blueprint/part-1/0_Abstract.md @@ -29,7 +29,7 @@ The board must store hardcoded cryptographic keys in order to verify among other the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and **SHE** to enhance the security of their board. - + Domain | Object | Recommendations -------------------- | ---------- | ---------------------------------- @@ -37,7 +37,7 @@ Hardware-Integrity-1 | Bootloader | Must control bootloader integrity. Hardware-Integrity-2 | Board | Must use a HSM. Hardware-Integrity-3 | RTC | Must not be alterable. - + -------------------------------------------------------------------------------- @@ -45,7 +45,7 @@ Hardware-Integrity-3 | RTC | Must not be alterable. ## Certificates - + Domain | Object | Recommendations ---------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- @@ -53,13 +53,13 @@ Hardware-Certificate-1 | System | Shall allow storing dedicated certificates. Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy. Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust. - + -------------------------------------------------------------------------------- ## Memory - + Domain | Object | Recommendations ----------------- | ---------- | ------------------------------------------------------------------------------------ @@ -67,4 +67,4 @@ Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key Hardware-Memory-2 | Bootloader | Internal NVM only Hardware-Module-3 | - | HSM must be used to secure keys. - + diff --git a/security-blueprint/part-2/0_Abstract.md b/security-blueprint/part-2/0_Abstract.md index 5ebb750..4574ecf 100644 --- a/security-blueprint/part-2/0_Abstract.md +++ b/security-blueprint/part-2/0_Abstract.md @@ -2,13 +2,13 @@ ## Abstract - + Domain | Improvement --------------- | ---------------------------------------------------- Boot-Abstract-1 | More generic and add examples (The chain of trust). - + **Boot Hardening**: Steps/requirements to configure the boot sequence, in order to restrict the device from executing anything other than the approved software @@ -29,13 +29,13 @@ 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 diff --git a/security-blueprint/part-2/1-Image.md b/security-blueprint/part-2/1-Image.md index c0eb0b6..453b397 100644 --- a/security-blueprint/part-2/1-Image.md +++ b/security-blueprint/part-2/1-Image.md @@ -8,14 +8,14 @@ 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` - + -------------------------------------------------------------------------------- @@ -38,7 +38,7 @@ CONFIG_DEFAULT_DEVICE_TREE: Specifies the default Device Tree used for the run-t 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_ ------------------------- | ---------------------------- | -------- @@ -49,4 +49,4 @@ Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_ Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_ Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_ - + diff --git a/security-blueprint/part-2/2-Communication-modes.md b/security-blueprint/part-2/2-Communication-modes.md index d3a823c..d3539f8 100644 --- a/security-blueprint/part-2/2-Communication-modes.md +++ b/security-blueprint/part-2/2-Communication-modes.md @@ -21,7 +21,7 @@ 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_ -------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- @@ -31,7 +31,7 @@ Boot-Communication-3 | `Ethernet` | _Disabled_ Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_ Boot-Communication-5 | `Serial ports` | _Disabled_ - + Domain | `Config` name | _State_ ------------------------ | ----------------------- | ------------- @@ -41,7 +41,7 @@ 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_ - + -------------------------------------------------------------------------------- @@ -50,25 +50,25 @@ Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_ Preferably no network interface is allowed, but if required, then the enabled services should be restricted to only those used. - + 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 @@ -78,12 +78,12 @@ In U-Boot following flash memory commands shall be disabled: **NAND**: Support for nand flash access available through `do_nand` has to be disabled. - + Domain | `Command` name | _State_ -------------------------- | -------------- | --------- Boot-Communication-Flash-1 | `do_nand` | _Disable_ - + Similarly sboot should disable flash access support through command line if any. diff --git a/security-blueprint/part-2/3-Consoles.md b/security-blueprint/part-2/3-Consoles.md index 5adad3f..366573b 100644 --- a/security-blueprint/part-2/3-Consoles.md +++ b/security-blueprint/part-2/3-Consoles.md @@ -5,7 +5,7 @@ Serial console output shall be disabled. To disable console output in U-Boot, set the following macros: - + Domain | `Config` name | `Value` ---------------------- | --------------------------------------- | --------- @@ -13,24 +13,24 @@ 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 undefined 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. @@ -49,7 +49,7 @@ environment variable and not in non-volatile memory. Remove configuration options related to non-volatile memory, such as: - + Domain | `Config` name | _State_ -------------------------- | ---------------------------- | --------- @@ -66,7 +66,7 @@ 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` - + -------------------------------------------------------------------------------- @@ -88,7 +88,7 @@ mtest : Simple ram read/write test. loopw : Infinite write loop on address range. ``` - + Domain | `Command` name | _State_ ----------------------- | -------------- | ---------- @@ -102,6 +102,6 @@ Boot-Consoles-MemDump-7 | `mdc` | _Disabled_ Boot-Consoles-MemDump-8 | `mtest` | _Disabled_ Boot-Consoles-MemDump-9 | `loopw` | _Disabled_ - + Similarly, memory dump support shall be disabled from sboot. diff --git a/security-blueprint/part-3/0_Abstract.md b/security-blueprint/part-3/0_Abstract.md index 3fb8831..bdec985 100644 --- a/security-blueprint/part-3/0_Abstract.md +++ b/security-blueprint/part-3/0_Abstract.md @@ -3,13 +3,13 @@ Definition: "A hypervisor or virtual machine monitor (VMM) is computer software, firmware or hardware that creates and runs virtual machines". - + Domain | Improvement --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)). - + ## Native or Bare-metal hypervisors diff --git a/security-blueprint/part-4/1-General.md b/security-blueprint/part-4/1-General.md index 013762f..3653904 100644 --- a/security-blueprint/part-4/1-General.md +++ b/security-blueprint/part-4/1-General.md @@ -4,13 +4,13 @@ Kernel should controls access with labels and policy. - + Domain | Object | Recommendations -------------------- | ------ | -------------------- Kernel-General-MAC-1 | SMACK | Must implement a MAC - + -------------------------------------------------------------------------------- @@ -18,13 +18,13 @@ Kernel-General-MAC-1 | SMACK | Must implement a MAC This prevents someone who gets root from supplanting the kernel. This can be used as a way to bypass signed kernels. - + Domain | `Config` name | `Value` ---------------------- | -------------- | ------- Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` - + -------------------------------------------------------------------------------- @@ -32,13 +32,13 @@ Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n` 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` - + -------------------------------------------------------------------------------- @@ -46,13 +46,13 @@ Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n` 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` - + -------------------------------------------------------------------------------- @@ -60,13 +60,13 @@ Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n` 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` - + -------------------------------------------------------------------------------- @@ -74,13 +74,13 @@ Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n` The firmware auto loading helper, which is a utility executed by the kernel on `hotplug` events requiring firmware, needs to be set `setuid`. As a result of this, the helper utility is an attractive target for attackers with control of physical ports on the device. Disabling this configuration that is supported in **Linux 3.9 and greater**. - + Domain | `Config` name | `Value` --------------------------- | ------------------------------ | ------- Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n` - + -------------------------------------------------------------------------------- @@ -90,13 +90,13 @@ When fuzzing the kernel or attempting kernel exploits attackers are likely to tr 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` - + -------------------------------------------------------------------------------- @@ -110,14 +110,14 @@ The `CONFIG_PACKET_DIAG` configuration is supported in **Linux 3.7 and greater** 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` - + -------------------------------------------------------------------------------- @@ -127,13 +127,13 @@ 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 | `BPF_JIT` | `n` - + -------------------------------------------------------------------------------- @@ -141,13 +141,13 @@ Kernel-General-BPF_JIT-1 | `BPF_JIT` | `n` 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` - + -------------------------------------------------------------------------------- @@ -157,7 +157,7 @@ Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y` 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_ ------------------------ | ------------------- | ---------- @@ -165,19 +165,19 @@ Kernel-General-Drivers-1 | `USB` | _Disabled_ Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_ Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_ - + -------------------------------------------------------------------------------- ## Position Independent Executables - + Domain | `compiler` and `linker` options | _State_ -------------------------------- | ------------------------------- | -------- Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_ - + Produce a position independent executable on targets which supports it. @@ -187,14 +187,14 @@ Produce a position independent executable on targets which supports it. `-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. @@ -206,10 +206,10 @@ During program load, all dynamic symbols are resolved, allowing for the complete It is recommended that dynamic linking should generally not be allowed. This will avoid the user from replacing a library with malicious library. All libraries should be linked statically, but this is difficult to implement. - + Domain | `compiler` and `linker` options | _State_ ------------------------------- | ------------------------------- | -------- Kernel-General-LibraryLinking-1 | `-static` | _Enable_ - + diff --git a/security-blueprint/part-4/2-Memory.md b/security-blueprint/part-4/2-Memory.md index 07ddbc9..9cc9c16 100644 --- a/security-blueprint/part-4/2-Memory.md +++ b/security-blueprint/part-4/2-Memory.md @@ -6,13 +6,13 @@ The /dev/kmem file in Linux systems is directly mapped 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. @@ -22,13 +22,13 @@ In case applications in userspace need /dev/kmem support, it should be available 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` - + -------------------------------------------------------------------------------- @@ -36,13 +36,13 @@ Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n` 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` - + -------------------------------------------------------------------------------- @@ -54,14 +54,14 @@ There is a /proc/kallsyms file which exposes the kernel memory space address of 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` - + -------------------------------------------------------------------------------- @@ -73,13 +73,13 @@ This configuration is supported in **Linux 3.11 and greater** and thus should on 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` - + -------------------------------------------------------------------------------- @@ -89,13 +89,13 @@ The /dev/mem file in Linux systems is directly mapped to physical memory. This c 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` - + -------------------------------------------------------------------------------- @@ -107,25 +107,25 @@ Disable the process_vm_*v syscalls which allow one process to peek/poke the virt 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. @@ -133,12 +133,12 @@ Emit extra code to check for buffer overflows, such as stack smashing attacks. ## Detect Buffer Overflows - + Domain | `compiler` and `linker` options | `Value` ------------------------------- | ------------------------------- | ------- Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2` - + Helps detect some buffer overflow errors. diff --git a/security-blueprint/part-4/3-Consoles.md b/security-blueprint/part-4/3-Consoles.md index 5cb2298..c6cf80a 100644 --- a/security-blueprint/part-4/3-Consoles.md +++ b/security-blueprint/part-4/3-Consoles.md @@ -4,7 +4,7 @@ The serial console should be disabled to prevent an attacker from accessing this powerful interface. - + Domain | `Config` name | `Value` ------------------------ | ---------------------------- | ------- @@ -13,7 +13,7 @@ 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` - + -------------------------------------------------------------------------------- @@ -23,7 +23,7 @@ The kernel command-line is used to control many aspects of the booting kernel, a Set the kernel command line in the `CONFIG_CMDLINE KConfig` item and then pass no arguments from the bootloader. - + Domain | `Config` name | `Value` ----------------------------- | ------------------------- | ----------------------------------- @@ -31,7 +31,7 @@ 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. @@ -41,13 +41,13 @@ It is recommended that any per-device settings (e.g: MAC addresses, serial numbe 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` - + -------------------------------------------------------------------------------- @@ -55,13 +55,13 @@ Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n` 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` - + -------------------------------------------------------------------------------- @@ -69,10 +69,10 @@ Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n` This will make possible to plug wrapper-driven binary formats into the kernel. It enables support for binary formats other than ELF. Providing the ability to use alternate interpreters would assist an attacker in discovering attack vectors. - + Domain | `Config` name | `Value` ------------------------------ | -------------------- | ------- Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n` - + diff --git a/security-blueprint/part-4/4-Debug.md b/security-blueprint/part-4/4-Debug.md index c8d5de0..5a1eb24 100644 --- a/security-blueprint/part-4/4-Debug.md +++ b/security-blueprint/part-4/4-Debug.md @@ -6,13 +6,13 @@ No debuggers shall be present on the file system. This includes, but is not limi 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. @@ -22,13 +22,13 @@ These kernel debug symbols are enabled by other config items in the kernel. Care 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` - + -------------------------------------------------------------------------------- @@ -36,13 +36,13 @@ Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n` 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` - + -------------------------------------------------------------------------------- @@ -50,14 +50,14 @@ Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n` 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` - + -------------------------------------------------------------------------------- @@ -65,13 +65,13 @@ Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n` 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` - + -------------------------------------------------------------------------------- @@ -79,14 +79,14 @@ Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n` 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. @@ -98,13 +98,13 @@ In some kernel versions, disabling this requires also disabling `CONFIG_EMBEDDED 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` - + -------------------------------------------------------------------------------- @@ -112,13 +112,13 @@ Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n` 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` - + -------------------------------------------------------------------------------- @@ -128,13 +128,13 @@ Core dumps provide a lot of debug information for hackers. So disabling core dum 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` - + -------------------------------------------------------------------------------- @@ -146,17 +146,17 @@ When attackers try to develop "run anywhere" exploits for kernel vulnerabilities **/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_ ---------------------------- | --------------------------- | ----------------------------- @@ -165,7 +165,7 @@ Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_ Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_ - + -------------------------------------------------------------------------------- @@ -175,13 +175,13 @@ When attackers try to develop "run anywhere" exploits for vulnerabilities, they **/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. @@ -193,10 +193,10 @@ Enable the below compiler and linker options when building user-space applicatio It is extremely important to not expose the kernel configuration used on a production device to a potential attacker. With access to the kernel config, it could be possible for an attacker to build a custom kernel for the device that may disable critical security features. - + Domain | `Config` name | `Value` --------------------- | ----------------- | ------- Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n` - + diff --git a/security-blueprint/part-4/5-FileSystems.md b/security-blueprint/part-4/5-FileSystems.md index e5ef733..78f2050 100644 --- a/security-blueprint/part-4/5-FileSystems.md +++ b/security-blueprint/part-4/5-FileSystems.md @@ -8,14 +8,14 @@ To reduce the attack surface, file system data is parsed by the kernel, so any l 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` - + -------------------------------------------------------------------------------- @@ -35,7 +35,7 @@ There are several security restrictions that can be set on a filesystem when it The following flags shall be used for mounting common filesystems: - + Domain | `Partition` | `Value` -------------------------- | ------------------- | ----------------------------------------------------------------- @@ -47,14 +47,14 @@ Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `no Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`. Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`. - + If `CONFIG_DEVTMPFS_MOUNT` is set, then the kernel will mount /dev and will not apply the `nosuid`, `noexec` options. Either disable `CONFIG_DEVTMPFS_MOUNT` or add a remount with `noexec` and `nosuid` options to system startup. - + Domain | `Config` name | _State_ or `Value` -------------------------- | ----------------------- | ----------------------------------------------------------------------- Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. - + diff --git a/security-blueprint/part-5/0_Abstract.md b/security-blueprint/part-5/0_Abstract.md index 4cbd17a..e724321 100644 --- a/security-blueprint/part-5/0_Abstract.md +++ b/security-blueprint/part-5/0_Abstract.md @@ -15,12 +15,12 @@ to deal with, we must: - 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 diff --git a/security-blueprint/part-5/1-MAC.md b/security-blueprint/part-5/1-MAC.md index 9cfc150..02a0e37 100644 --- a/security-blueprint/part-5/1-MAC.md +++ b/security-blueprint/part-5/1-MAC.md @@ -1,12 +1,12 @@ # 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 @@ -58,7 +58,7 @@ Label | Name | Execution **SMACK** | File Access **SMACK** `^` | 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 @@ -67,14 +67,14 @@ Label | Name | Execution **SMACK** | File Access **SMACK** - 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. - + -------------------------------------------------------------------------------- @@ -95,7 +95,7 @@ Label | Name | Execution **SMACK** | `System::Log` | Log | `rwa` for System label `xa` for user label | None `System::Sub` | SubSystem | Subsystem Config files | SubSystem only - + Domain | `Label` name | Recommendations ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------- @@ -105,7 +105,7 @@ Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory la 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. - + -------------------------------------------------------------------------------- @@ -125,7 +125,7 @@ Label | Name | Execution **SMACK** `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 ------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- @@ -133,4 +133,4 @@ Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A 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. - + diff --git a/security-blueprint/part-5/2-SystemD.md b/security-blueprint/part-5/2-SystemD.md index 903df11..35abe16 100644 --- a/security-blueprint/part-5/2-SystemD.md +++ b/security-blueprint/part-5/2-SystemD.md @@ -6,14 +6,14 @@ - 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. diff --git a/security-blueprint/part-5/3-SystemBus.md b/security-blueprint/part-5/3-SystemBus.md index 2a98124..e2af387 100644 --- a/security-blueprint/part-5/3-SystemBus.md +++ b/security-blueprint/part-5/3-SystemBus.md @@ -14,11 +14,11 @@ 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) - \ No newline at end of file + diff --git a/security-blueprint/part-5/4-Services.md b/security-blueprint/part-5/4-Services.md index 18f56ec..013f693 100644 --- a/security-blueprint/part-5/4-Services.md +++ b/security-blueprint/part-5/4-Services.md @@ -1,13 +1,13 @@ # System services and daemons - + Domain | Improvement ------------------- | ----------- Platform-Services-1 | SystemD ? Platform-Services-2 | Secure daemon ? - + ## Tools @@ -25,7 +25,7 @@ Platform-Services-2 | Secure daemon ? - **alsa** is a software framework and part of the Linux kernel that provides an **API** for sound card device drivers. - + Domain | `Tool` name | _State_ -------------------- | ----------- | ------- @@ -34,4 +34,4 @@ Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager. Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format. Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers. - + diff --git a/security-blueprint/part-5/5-AppFw.md b/security-blueprint/part-5/5-AppFw.md index 9f67b16..923c591 100644 --- a/security-blueprint/part-5/5-AppFw.md +++ b/security-blueprint/part-5/5-AppFw.md @@ -8,7 +8,7 @@ The application framework manages: - 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 @@ -20,19 +20,19 @@ The application framework manages: 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. @@ -50,13 +50,13 @@ permissions: Currently in AGL, this task depends on a policy-checker service Cynara interact with **D-Bus** in order to deliver this information. - + Domain | Object | Recommendations ----------------------- | ----------- | ------------------------------------- Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service. - + ### Policies diff --git a/security-blueprint/part-5/6-Utilities.md b/security-blueprint/part-5/6-Utilities.md index d723c10..309cbc4 100644 --- a/security-blueprint/part-5/6-Utilities.md +++ b/security-blueprint/part-5/6-Utilities.md @@ -5,13 +5,13 @@ 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 @@ -21,7 +21,7 @@ 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_ --------------------- | ---------------------------------------------------- | ---------- @@ -69,10 +69,10 @@ Platform-Utilities-41 | `tail` (busybox) | _ Platform-Utilities-42 | `tee` (busybox) | _Enabled_ Platform-Utilities-43 | `test` (busybox) | _Enabled_ - + The _Enabled_ Unix/Linux utilities above shall be permitted as they are often used in the start-up scripts and for USB logging. If any of these utilities are not required by the device then those should be removed. - + diff --git a/security-blueprint/part-5/7-Users.md b/security-blueprint/part-5/7-Users.md index 9fc7a65..af5a686 100644 --- a/security-blueprint/part-5/7-Users.md +++ b/security-blueprint/part-5/7-Users.md @@ -24,18 +24,18 @@ 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_ --------------------- | -------------- | ------------- @@ -45,7 +45,7 @@ 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. @@ -59,14 +59,14 @@ 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 diff --git a/security-blueprint/part-6/1-Installation.md b/security-blueprint/part-6/1-Installation.md index f9ea74d..e2972ce 100644 --- a/security-blueprint/part-6/1-Installation.md +++ b/security-blueprint/part-6/1-Installation.md @@ -1,29 +1,29 @@ # Local - + Domain | Improvement -------------------------- | ------------------------------ Application-Installation-1 | Talk about AppFw offline mode. - + ## Installation Applications can be delivered and installed with the base image using a special offline-mode provided by the **AppFw**. Apps can also be installed at run time. - + During early release, default Apps are installed on the image at first boot. - + - + Domain | Object | Recommendations -------------------------- | --------- | ----------------------------------------------------------------------- Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image. Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good. - + diff --git a/security-blueprint/part-6/3-Signature.md b/security-blueprint/part-6/3-Signature.md index 782eb10..f7b48db 100644 --- a/security-blueprint/part-6/3-Signature.md +++ b/security-blueprint/part-6/3-Signature.md @@ -1,9 +1,9 @@ # App Signature - + Domain | Improvement ----------------------- | ---------------------------------------------------------- Application-Signature-1 | Add content (see secure build in Secure development part). - + diff --git a/security-blueprint/part-6/4-Services.md b/security-blueprint/part-6/4-Services.md index 4ef9afc..d0414f0 100644 --- a/security-blueprint/part-6/4-Services.md +++ b/security-blueprint/part-6/4-Services.md @@ -1,10 +1,10 @@ # Services - + Domain | Improvement ---------------------- | ------------ Application-Services-1 | Add content (Which services?). Application-Services-2 | Add Binder. - + diff --git a/security-blueprint/part-7/0_Abstract.md b/security-blueprint/part-7/0_Abstract.md index 162aced..f7acbe5 100644 --- a/security-blueprint/part-7/0_Abstract.md +++ b/security-blueprint/part-7/0_Abstract.md @@ -4,13 +4,13 @@ This part shows different Connectivity attacks on the car. - + Domain | Improvement ----------------------- | ----------------- Connectivity-Abstract-1 | Improve abstract. - + -------------------------------------------------------------------------------- diff --git a/security-blueprint/part-7/1-BusAndConnectors.md b/security-blueprint/part-7/1-BusAndConnectors.md index 843a921..0cdedc2 100644 --- a/security-blueprint/part-7/1-BusAndConnectors.md +++ b/security-blueprint/part-7/1-BusAndConnectors.md @@ -25,13 +25,13 @@ packets. We just describe them a bit: 2001 on everywhere in a car, where the bandwidth and versatility of a **CAN** network is not required. - + 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. @@ -42,7 +42,7 @@ 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 ----------------------------------------- | --------- | ---------------------------------------------------------------------- @@ -51,4 +51,4 @@ Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchan Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable. Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages. - + diff --git a/security-blueprint/part-7/2-Wireless.md b/security-blueprint/part-7/2-Wireless.md index a324673..d3fda8b 100644 --- a/security-blueprint/part-7/2-Wireless.md +++ b/security-blueprint/part-7/2-Wireless.md @@ -6,13 +6,13 @@ 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: @@ -26,13 +26,13 @@ We will see the following parts: - [NFC](#nfc) - + Domain | Improvement ----------------------- | ------------------------------------------- Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). - + -------------------------------------------------------------------------------- @@ -89,7 +89,7 @@ We can differentiate existing attacks on wifi in two categories: Those on - Should protect data sniffing. - + Domain | Tech name or object | Recommendations ---------------------------- | ------------------- | ------------------------------------------------------------------------- @@ -99,7 +99,7 @@ Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffin 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) @@ -136,7 +136,7 @@ for more information. avoid using the "Just Works" association model. The device must verify that an authenticated link key was generated during pairing. - + Domain | Tech name | Recommendations --------------------------------- | ------------- | ------------------------------------------------------------ @@ -146,7 +146,7 @@ Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" 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), @@ -179,14 +179,14 @@ for more information. - 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. @@ -205,13 +205,13 @@ for more information. - 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. - + -------------------------------------------------------------------------------- @@ -234,11 +234,11 @@ Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concernin Certification Mark shows that products meet global interoperability standards. - NFC Modified Miller coding is preferred over NFC Manchester coding. - + Domain | Tech name | Recommendations --------------------------- | --------- | ------------------------------------------------------ Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks. Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles. - + diff --git a/security-blueprint/part-7/3-Cloud.md b/security-blueprint/part-7/3-Cloud.md index 4d37ff4..67c9c76 100644 --- a/security-blueprint/part-7/3-Cloud.md +++ b/security-blueprint/part-7/3-Cloud.md @@ -10,14 +10,14 @@ 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. - + -------------------------------------------------------------------------------- @@ -50,7 +50,7 @@ Application-Cloud-Download-2 | Authorization | Must implement Authorization p - + Domain | Object | Recommendations ---------------------------------- | ------------- | ---------------------------------------------------------- @@ -60,7 +60,7 @@ Application-Cloud-Infrastructure-3 | Test | Should implement scanning t 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. - + -------------------------------------------------------------------------------- @@ -98,10 +98,10 @@ to configure each application to **IPSec** standards. 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/security-blueprint/part-8/1-FOTA.md b/security-blueprint/part-8/1-FOTA.md index a65a239..add068e 100644 --- a/security-blueprint/part-8/1-FOTA.md +++ b/security-blueprint/part-8/1-FOTA.md @@ -20,13 +20,13 @@ the sboot/U-Boot code, the board specific implementation of the Secure Loader will have to manage the entire USB initialization, enumeration, and read/write access to the mass storage device. - + Domain | Object | Recommendations ------------- | ----------------------------------------- | --------------- Update-FOTA-1 | Integrity, confidentiality and legitimacy | Must be secure. - + Different possible type of **FOTA**: diff --git a/security-blueprint/part-8/2-SOTA.md b/security-blueprint/part-8/2-SOTA.md index 287a91a..ab8d9fd 100644 --- a/security-blueprint/part-8/2-SOTA.md +++ b/security-blueprint/part-8/2-SOTA.md @@ -3,10 +3,10 @@ **SOTA** is made possible by **AppFw** (See Platform part). It will be possible to manage in a simple way the packets (i.g. Android like). - + Domain | Improvement ------------- | ----------------- Update-SOTA-1 | Part to complete. - + diff --git a/security-blueprint/part-9/0_Abstract.md b/security-blueprint/part-9/0_Abstract.md index 2dbc17b..25d3f35 100644 --- a/security-blueprint/part-9/0_Abstract.md +++ b/security-blueprint/part-9/0_Abstract.md @@ -11,23 +11,23 @@ Tools like: - [Code optimisation](https://github.com/jduck/lk-reducer). - [Kernel Drivers test](https://github.com/ucsb-seclab/dr_checker) with [docs](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pdf). - + Domain | Improvement ----------------------- | ------------ SecureDev-SecureBuild-1 | Add content. - + ## App/Widget signatures - + Domain | Improvement ---------------------- | ------------ SecureDev-Signatures-1 | Add content. - + ## Code audit @@ -36,14 +36,14 @@ compliance with related good practices. - [Continuous Code Quality](https://www.sonarqube.org/). - + Domain | Improvement --------------------- | ----------------------------------------------------- SecureDev-CodeAudit-1 | Add CVE analyser. SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). - + ### SATS -- cgit 1.2.3-korg