diff options
Diffstat (limited to 'sec-blueprint/07-system-hardening.md')
| -rw-r--r-- | sec-blueprint/07-system-hardening.md | 1250 |
1 files changed, 1250 insertions, 0 deletions
diff --git a/sec-blueprint/07-system-hardening.md b/sec-blueprint/07-system-hardening.md new file mode 100644 index 0000000..5ffe501 --- /dev/null +++ b/sec-blueprint/07-system-hardening.md @@ -0,0 +1,1250 @@ +--- + +title : System Hardening +date : 2017-05-23 +categories: security, hardening, automotive +tags: security, hardening, architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +# Overview + +## Scope + +This document provides recommended guidelines for adding protection to an +embedded system. The information contained in this document is applicable +to systems based on Automotive Grade Linux. + +## Limitations + +- This document is based on knowledge and research gained from looking + at security desktop and server versions of Linux as well as Android + exploits and hardening. + +- Some kernel configuration options can have an impact on performance. + This will be noted where applicable. + +## Document Structure + +This document has been divided into three sections; REQUIREMENTS, +RECOMMENDATIONS, and VALIDATION. The REQUIREMENTS section details +explicit requirements that must be adhered to for the embedded +device. +The RECOMMENDATIONS section details best practices, and some +recommended security settings for the embedded device. +The third section, VALIDATION, provides reference scripts and test procedures that +can be used to verify adherence with the REQUIREMENTS detailed in the +first section of this guide. + +## Hardening + +The term *Hardening* refers to the tools, techniques and processes +required in order to reduce the attack surface on an embedded system, +such as an embedded control unit (ECU) or other managed device. +The target for all hardening activities is to prevent the execution of +invalid binaries on the device, and to prevent copying of security +related data from the device. +There are three main areas of focus for hardening an embedded device: + +**Boot Hardening**: Steps/requirements to configure the boot sequence, +in order to restrict the device from executing anything other than the +approved software image. + +**System Hardening**: Best practices associated with the configuration +of an embedded Linux based operating system. This section includes both +hardening of the kernel itself, as well as specific configurations and +patches used to protect against known vulnerabilities within the build +and configuration of the root filesystem. + +**Application Hardening:** Best practices to apply to the build and +release of user space applications, in order to reduce the number of +attack surfaces used by potential attackers. + +## Secure Boot Software Flow Steps + +1. After power on, the processor will perform the verification + of the Stage 1 boot image, the stage 2 boot image and the Secure + loader image. + + a. If any of the images fail the verification process the device + will not boot. + +2. Upon successful verification of all of the boot and loader images, + the secure process will initiate the Stage 1 boot process. + +3. The Stage 1 boot process will perform processor initialization, and + then initiate the Stage 2 boot process. + +4. The Stage 2 boot process will initiate the Secure Loader, which will + process any customer specific customizations (e.g. front panel + of ECU, USB based image updates, etc). + +5. The Secure Loader will check to determine if there are any updates + to be processed. If the update settings indicate that an upgrade + should occur then the Secure Loader will will determine the correct + action based on the nature of the upgrades: + + a. If the Secure Loader determines that an upgrade was performed + (or attempted), it will initiate the reboot process. + + b. If no upgrades were processed: then the Secure Loader will pass + control back to the Stage 2 boot process for further processing + +6. The Stage 2 boot process will continue with the boot process, by + performing a verification of the kernel image prior to the load of + that image + + a. If the kernel image verification fails, the Stage 2 boot loader + will not boot + +8. The Stage 2 boot loader will load the successfully verified kernel + and boot the linux OS + +9. The booted Linux OS will perform the normal Linux init sequence + +10. The Linux init process will start the required applications and + services as described in the init process and present on the rootfs. + +# Requirements + + For the purposes of reference and explanation, we are providing guidance + on how to configure an embedded device that runs with a 3.10.17 + Linux kernel, and includes the use of U-Boot as the *Stage 2* + These requirements must still be met by manufacturers that + opt to build using an alternative version of the Linux kernel. + +## Hardened Boot + +### Boot image selection + +The boot process shall be uninterruptable and shall irrevocably boot the +image as specified in the boot environment. + +In U-Boot set the “**bootdelay**” environment variable and/or define +CONFIG\_BOOTDELAY to -2. + +### Verifying Authenticity of booting image + +It shall not be possible to boot from an unverified image. + +The secure boot feature in U-Boot shall be enabled. The secure boot +feature is available from U-Boot 2013.07 version. + +To enable the secure boot feature, enable the following features: + +``` +CONFIG_FIT: enables support for Flat Image Tree (FIT) uImage format. +CONFIG_FIT_SIGNATURE: enables signature verification of FIT images. +CONFIG_RSA: enables RSA algorithm used for FIT image verifitcation. +CONFIG_OF_CONTROL: enables Flattened Device Tree (FDT) configuration. +CONFIG_OF_SEPARATE: enables separate build of u-Boot from the device tree. +CONFIG_DEFAULT_DEVICE_TREE: specifies the default Device Tree used for the +run-time configuration of U-Boot. +``` + +Generate the U-Boot image with public keys to validate and load the +image. It shall use RSA2048 and SHA256 for authentication. + +### Disable USB support + +To disable USB support in U-Boot, following configs shall not be +defined: + +``` +CONFIG_CMD_USB: enables basic USB support and the usb command +CONFIG_USB_UHCI: defines the lowlevel part. +CONFIG_USB_KEYBOARD: enables the USB Keyboard +CONFIG_USB_STORAGE: enables the USB storage devices +CONFIG_USB_HOST_ETHER: enables USB ethernet adapter support +``` + +### Console / Remote Access + +Serial console output shall be disabled. To disable console output in +U-Boot, set the following macros: + +``` +CONFIG_SILENT_CONSOLE +CONFIG_SYS_DEVICE_NULLDEV +CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC +``` + +and set “***silent”*** environment variable. + +For the Secure loader, disable the traces by undefining the below macro + +``` +INC_DEBUG_PRINT +``` + +For sboot proper configuration needs to be done to disable the serial +console. + +### Field upgrades + +Field upgrades can be achieved securely by using a Secure Loader. +This loader will authenticate an incoming image (USB,Serial, Network) +prior to writing it to the flash memory on the device. It should not be +possible to write to flash from bootloader (U-Boot). Note that because + USB support is to be disabled within the sboot/U-Boot code, the board +specific implementation of the Secure Loader will have to manage the +entire USB initialization, enumeration, and read/write access to the +mass storage device. + +### Disable USB, Serial, Docsis support + +Disable USB support in sboot. In addition, disable unnecessary communication +modes like Ethernet, Serial ports, DOCSIS in U-Boot and sboot that are +not necessary. + +### Immutable Environment variables + +In U-Boot, ensure Kernel command line, boot commands, boot delay and +other environment variables are immutable. This will prevent +side-loading of alternate images, by restricting the boot selection to +only the image in FLASH. + +The environment variables shall be part of text region in U-Boot as +default environment variable and not in non-volatile memory. + +Remove configuration options related to non-volatile memory such as: + +``` +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_ENV_IS_IN_EEPROM +#define CONFIG_ENV_IS_IN_FLASH +#define CONFIG_ENV_IS_IN_DATAFLASH +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_ENV_IS_IN_FAT +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_IS_IN_NVRAM +#define CONFIG_ENV_IS_IN_ONENAND +#define CONFIG_ENV_IS_IN_SPI_FLASH +#define CONFIG_ENV_IS_IN_REMOTE +#define CONFIG_ENV_IS_IN_UBI +``` + +and include the following definition: + +``` +#define** CONFIG_ENV_IS_NOWHERE +``` + +## Kernel Hardening + + The following sub-sections contain information on various kernel + configuration options to enhance the security measures in the kernel + and also for applications compiled to take advantage of these security + features. + Additionally, there are also configuration options that + close known vulnerable configuration options. + Here’s a high level summary of various kernel configurations that + shall be required for deployment. + +### Disable the serial console + + The serial console should be disabled to prevent an attacker from + accessing this powerful interface. + +```bash + CONFIG_SERIAL_8250=n + CONFIG_SERIAL_8250_CONSOLE=n + CONFIG_SERIAL_CORE=n + CONFIG_SERIAL_CORE_CONSOLE=n +``` + +### Restrict access to kernel memory through device file + + The /dev/kmem file in Linux systems is directly mapped to kernel + virtual memory. + This can be disastrous if an attacker gains root + access, as the attacker would have direct access to kernel virtual + memory. + + To disable the /dev/kmem file, which is very infrequently used by + applications, the following kernel option should be set in the + compile-time kernel configuration: + +``` + CONFIG_DEVKMEM=n +``` + + In case applications in userspace need /dev/kmem support, it should be + available only for authenticated applications. + +### Bake-in the kernel command-line + + The kernel command-line is used to control many aspects of the booting + kernel, and is prone to tampering as they are passed in RAM with + little to no reverse validation on these parameters. + To prevent this type of attack, the kernel shall be configured to ignore command line + arguments, and use pre-configured (compile time) options instead. + + Set the kernel command line in the CONFIG\_CMDLINE KConfig item and + then pass no arguments from the bootloader. + +```bash + CONFIG_CMDLINE_BOOL=y + CONFIG_CMDLINE=”insert kernel command line here” + CONFIG_CMDLINE_OVERRIDE=y +``` + + It is recommended that any per-device settings (eg. MAC addresses, + serial numbers, etc.) be stored and accessed from read-only memory (or + files), and that any such parameters be verified (signature checking) + prior to their use. + +### Disable kernel debug symbols + + Debug symbols should always be removed from production kernels as they + provide a lot of information to attackers. + +```bash + CONFIG_DEBUG_INFO=n +``` + + These kernel debug symbols are enabled by other config items in the + kernel. + Care should be taken to disable those also. + If CONFIG\_DEBUG\_INFO cannot be disabled then enabling + CONFIG\_DEBUG\_INFO\_REDUCED is second best. + +### Disable access to a kernel core dump + + This kernel configuration disables access to a kernel core dump from + user space -- if enabled it gives attackers a useful view into kernel + memory. + +```bash + CONFIG_PROC_KCORE=n +``` + +### Disable KGDB + + The Linux kernel supports KGDB over USB and console ports. These + mechanisms are controlled by the kgdbdbgp and kgdboc kernel + command-line parameters. + It is important to ensure that no shipping + product contains a kernel with KGDB compiled-in. + +```bash + CONFIG_KGDB=n +``` + +### Disable Kprobes + + Kprobes enables you to dynamically break into any kernel routine and + collect debugging and performance information non-disruptively. + You can trap at almost any kernel code address, specifying a handler + routine to be invoked when the breakpoint is hit. + +```bash + CONFIG_KPROBES=n +``` + +### Disable Tracing + + FTrace enables the kernel to trace every kernel function. + Providing kernel trace functionality would assist an attacker in discovering attack vectors. + +```bash + CONFIG_FTRACE=n +``` + +### Disable Profiling + + Profiling and OProfile enables profiling the whole system, include the kernel, + kernel modules, libraries, and applications. + Providing profiling functionality + would assist an attacker in discovering attack vectors. + +```bash + CONFIG_OPROFILE=n + CONFIG_PROFILING=n +``` + +### Disable magic sysrq support + + On a few architectures, you can access a powerful debugger interface + from the keyboard. + The same powerful interface can be present on the serial console + – responding to serial break – of Linux on other architectures. + Disable to avoid potentially exposing this powerful backdoor. + +```bash + CONFIG_MAGIC_SYSRQ=n +``` + +### Disable OOPS print on BUG() + + The output from OOPS print can be helpful in Return Oriented + Programming (ROP) when trying to determine the effectiveness of an + exploit. + +```bash + CONFIG_DEBUG_BUGVERBOSE=n +``` + +### Disable kexec + + This prevents someone who gets root from supplanting the kernel. + This can be used as a way to bypass signed kernels. + +```bash + CONFIG_KEXEC=n +``` + +### Disable kernel IP autoconfiguration + + It is preferable to have IP configuration performed using a user-space + tool as these tend to have more validation. + We do not want the network + interface coming up until the system has come up properly. + +```bash + CONFIG_IP_PNP=n +``` + +### Disable /proc/config.gz + + It is extremely important to not expose the kernel configuration used + on a production device to a potential attacker. + With access to the + kernel config, it could be possible for an attacker to build a custom + kernel for the device that may disable critical security features. + +```bash + CONFIG_IKCONFIG=n +``` + +### Disable swap + + If not disabled, attackers can enable swap at runtime, add pressure to + the memory subsystem and then scour the pages written to swap for + useful information. + +```bash + CONFIG_SWAP=n +``` + +### Disable NFS file system + + While often enabled in development, when left enabled in production + builds this can be a very useful way for an attacker to get files onto + and off of an STB. + +```bash + CONFIG_NFSD=n + CONFIG_NFS_FS=n +``` + +### Disable support for binary formats other than ELF + + This will make possible to plug wrapper-driven binary formats into + the kernel. + It enables support for binary formats other than ELF. + Providing the ability to use alternate interpreters would assist an attacker in + discovering attack vectors + +```bash + CONFIG_BINFMT_MISC=n +``` + +### Disable “Load All Symbols” + + There is a /proc/kallsyms file which exposes the kernel memory space + address of many kernel symbols (functions, variables, etc.). + This information is useful to attackers in identifying kernel + versions/configurations and in preparing payloads for exploits of + kernel space. + + Both KALLSYMS\_ALL and KALLSYMS shall be disabled; + +```bash + CONFIG_KALLSYMS=n + CONFIG_KALLSYMS_ALL=n +``` + +### Disable Kernel Debugging + + There are development-only branches of code in the kernel enabled by + the DEBUG\_KERNEL conf. + This should be disabled to compile-out these branches. + +```bash + CONFIG_DEBUG_KERNEL=n +``` + + In some kernel versions, disabling this requires also disabling + CONFIG\_EMBEDDED, and CONFIG\_EXPERT Disabling CONFIG\_EXPERT makes it + impossible to disable \_COREDUMP, DEBUG\_BUGVERBOSE, \_NAMESPACES, + \_KALLSYMS and \_BUG. + In which case it is better to leave this enabled + than enable the others. + +### Disable the kernel debug filesystem + + The kernel debug filesystem presents a lot of useful information and + means of manipulation of the kernel to an attacker. + +```bash + CONFIG_DEBUG_FS=n +``` + +### Disable BUG() support + + The kernel will display backtrace and register information for BUGs + and WARNs in kernel space, making it easier for attackers to develop + exploits. + +```bash + CONFIG_BUG=n +``` + +### Disable Sysctl syscall support + + Enabling this will result in code being included that is hard to + maintain and not well tested. + +```bash + CONFIG_SYSCTL_SYSCALL=n +``` + +### Kernel Modules + +### Disable module unloading + + This stops an attacker unloading security focused kernel modules. + It will also prevent the attacker from removing evidence of any attempted + kernel tampering that may have been initiated by loading of a kernel + module. + +```bash + CONFIG_MODULE_UNLOAD=n +``` + +### Disable Forced Module Loading + + If enabled, then modules without version information or with + mismatched version information may be forcibly loaded into the kernel. + Disabling this configuration forces the attackers to build modules + with matched kernel sources and configuration in order to load them. + +```bash + CONFIG_MODULE_FORCE_LOAD=n +``` +### System Services + +#### Console & Remote Access + +- The kernel console interfaces shall be disabled. Do not pass any statements + of the following kind (e.g. console=ttyS0 console=tty0) on the kernel + command line. All of the console=<interface> statements should be + stripped and removed from the kernel command line. + +- The telnet server shall be disabled. + +- Do not start telnetd in init scripts. + +- Remove telnetd from the root file system. + +- Root login access via the console shall be disabled. + +- Do not run shell or getty on /dev/ttySx or /dev/console from + init scripts. + +- Root login access through remote access such as SSH shall + be disabled or completely removed + +#### Disable *sudo* for other users + + Remove the /etc/sudoers file from the root file system + + Remove the sudo command from the root file system. + +#### Mount /tmp file system as noexec + + A lot of malware can be stopped by not allowing files located in /tmp + to execute. + + The /etc/fstab file should contain a line for the /tmp directory with + the noexec mount option set as follows: + + tmpfs /tmp tmpfs noexec 0 0 + +#### User Account Management + + All user accounts shall have strong, non-default passwords. A strong + password is described to have all of the following attributes: + +- At least one upper-case letter + +- At least one numeric character + +- At least one lower-case letter + +- Password shall be eight or more characters in length + +- Shall not use a known, common pattern (e.g. Xxxxxxx\# + or Xxxxxxx\#\#) + +#### Remove known insecure services + + The following legacy services are inherently insecure and should be + avoided: + +- rlogind + +- rshd + +- rcmd + +- rexecd + +- rbootd + +- rquotad + +- rstatd + +- rusersd + +- rwalld + +- rhosts + +- rexd + + These services offer insufficient authentication, no encryption, and + are not considered secure. They shall be removed along with their + configuration files. + +### The mtd-utils shall not be present on the file system + + The mtd-utils binary package (also known as the Memory Technology + Device Utilities package) contains a collection of executable binaries + that allow a user to perform operations on raw flash devices. Here’s a + non-exhaustive sample of commonly used utilities that are part of the + mtd-utils package: + +- flash\_erase + +- flash\_eraseall + +- flashcp + +- flash\_lock + +- flash\_otp\_dump + +- flash\_otp\_info + +- flash\_unlock + +- mkfs.jffs2 + +- mkfs.ubifs + +- nanddump + +- nandtest + +- nandwrite + +- ubiattach + +- ubicrc32 + +- ubidetach + +- ubiformat + +- ubimkvol + +- ubinfo + +- ubinize + +- ubirename + +- ubirmvol + +- ubirsvol + +- ubiupdatevol + + The mtd-utils package as a whole (including all of its executable + binaries) shall not be present on the file system. Including these + binaries on the file system will facilitate an attacker’s ability to + read, write or otherwise gather information about raw flash devices + present on the system. + +### Debuggers shall not be present on the file system + + No debuggers shall be present on the file system. This includes, but + is not limited to, the GNU Debugger client/server (commonly known in + their short form names such as the gdb and gdbserver executable + binaries respectively), or the LLDB next generation debugger. + Including these binaries as part of the file system will facilitate an + attacker’s ability to reverse engineer and debug (either locally or + remotely) any process that is currently executing on the device. + +### Partition Mount Options + + There are several security restrictions that can be set on a + filesystem when it is mounted. Some common security options include, + but are not limited to: + + nosuid - Do not allow set-user-identifier or set-group-identifier bits + to take effect + + nodev - Do not interpret character or block special devices on the + filesystem + + noexec - Do not allow execution of any binaries on the mounted + filesystem + + ro - Mount filesystem as read-only + + The following flags shall be used for mounting common filesystems: + + +| Partition | Notes | +|------------------------------|---------------------------------------------------------------------------------------------| +| /boot | Use nosuid and nodev and consider using noexec. | +| /var & /tmp | In the /etc/fstab or vfstab file, add nosuid, nodev and noexec. | +| Non-Root local partitions | If the filesystem type is ext2 or ext3 and the mount point is not '/', add the nodev option.| +| Removable storage partitions | Add nodev, nosuid, and noexec options. | +| Temporary storage partitions | Add nodev, nosuid, and noexec options. | +| /dev/shm | Add nodev, nosuid, and noexec options. | +| /dev | Add nosuid, noexec options.\ | +| | Note: if CONFIG\_DEVTMPFS\_MOUNT is set then the kernel will mount /dev and will not apply | +| | the nosuid, noexec options. Either disable CONFIG\_DEVTMPFS\_MOUNT or add a remount with | +| | noexec and nosuid options to system startup. | + + +# Recommendations + +The following sections detail best practices that should be applied in +order to secure a device. +Although they are not currently listed as hard +requirements, they may be upgraded to requirements status in the future. +In addition, specific operators may change some of these recommendations +into requirements based on their specific needs and objectives. + +## Hardened Boot + +The boot loader consists of the Primary boot loader residing in OTP +memory, sboot, U-Boot and Secure loader residing in external flash (NAND +or SPI/NOR flash memory). The CPU on power on or reset executes the +primary boot loader. The OTP primary boot loader makes the necessary +initial system configuration and then loads the secondary boot loader +sboot from external flash memory to ram memory. The sboot then loads the +U-Boot along with the Secure loader. U-Boot then verifies and loads the +Kernel/system image before passing control to it. + +### Removal of memory dump commands + +In U-Boot, following commands shall be disabled to avoid memory dumps + +``` +md : Memory Display command + +mm : Memory modify command – auto incrementing address + +nm : Memory modify command – constant address + +mw : memory write + +cp : memory copy + +mwc : memory write cyclic + +mdc : memory display cyclic + +mtest : simple ram read/write test + +loopw : infinite write loop on address range +``` + +Similarly memory dump support shall be disabled from sboot + +### Disable flash access + +In U-Boot following flash memory commands shall be disabled: + +Nand: Support for nand flash access available through **do\_nand** has +to be disabled. + +Similarly sboot should disable flash access support through command line +if any. + +## Hardened System + +### Network + +#### Disable all Network Interfaces + + Preferably no network interface is allowed, but if required, then the + enabled services should be restricted to only those described in the + STB’s functional description. + +### Remove or Disable Unnecessary Services, Ports, and Devices. + + Services and utilities that do not have a defined purpose on a system + should be removed. If removal is not possible, but the service or + utility can be disabled, then it should be disabled. If a service or + utility is necessary, available secure configuration best practices + should be implemented. + + Telnet, FTP, and NFS have security weaknesses that are well known; + however, customers may have requirements to use these services. If + remote shell access and file transfer are required, then provide more + secure options, such as SSH and SFTP/SCP. + +### Restrict USB Ports + + Linux Kernel support for USB should be compiled-out if not required. + If it is needed, the Linux Kernel should be configured to only enable + the minimum required USB devices. + + User-initiated USB-filesystems should be treated with special care.. + + Whether or not the filesystems are mounted in userspace(FUSE), restricted + mount options should be observed. + +## Kernel Hardening + + The following sub-sections contain information on various kernel + configuration options that will require updating to a newer kernel + version in order to enhance the security measures in the kernel and + also for applications compiled to take advantage of these security + features. + + Additionally, there are also configuration options that close known + vulnerable configuration options. + Here’s a high level summary of the + various kernel configurations and which kernel version they pertain: + +| Kernel Configuration | Kernel Version | +|---------------------------------------|----------------| +| CONFIG\_UNIX\_DIAG=n |3.3+ | +| CROSS\_MEMORY\_ATTACH=n |3.5+ | +| CONFIG\_PANIC\_ON\_OOPS=y |3.5+ | +| CONFIG\_COREDUMP=n |3.7+ | +| CONFIG\_MODULE\_SIG\_FORCE=y |3.7+ | +| CONFIG\_PACKET\_DIAG=n |3.7+ | +| CONFIG\_FW\_LOADER\_USER\_HELPER=n |3.9+ | +| CONFIG\_CC\_STACKPROTECTOR=y |3.11+ | +| CONFIG\_USELIB=n |3.15+ | +| BPF\_JIT=n |3.16+ | +| CONFIG\_DEVMEM=n |4.0+ | + +### Build with Stack Protection + + Similar to the stack protector used for ELF programs in user-space, + the kernel can protect its internal stacks as well. + This configuration is supported in Linux 3.11 and greater and + thus should only be enabled for such versions. + This configuration also + requires building the kernel with the gcc compiler 4.2 or greater. + +```bash + CONFIG_CC_STACKPROTECTOR=y +``` + +### Disable access to /dev/mem + + The /dev/mem file in Linux systems is directly mapped to physical + memory. + This can be disastrous if an attacker gains root access, as + the attacker would have direct access to physical memory through this + convenient device file. + It may not always be possible to disable such + file, as some applications might need such support. + In that case then + this device file should be available only for authenticated + applications. + This configuration is supported in Linux 4.0 and greater + and thus should only be disabled for such versions. + +```bash + CONFIG_DEVMEM=n +``` + +### Disable cross-memory attach + + Disable the process\_vm\_\*v syscalls which allow one process to + peek/poke the virtual memory of another. + This configuration is + supported in Linux 3.5 and greater and thus should only be disabled + for such versions. +```bash + CROSS_MEMORY_ATTACH=n +``` + +### Disable core dumps + + Core dumps provide lot of debug information for hackers. + So disabling core dumps is recommended in production builds. + This configuration is + supported in Linux 3.7 and greater and thus should only be disabled + for such versions. + +```bash + CONFIG_COREDUMP=n +``` + +### Disable Legacy Linux Support + + There are some Kernel Configs which are present only to support legacy + binaries. + See also section 2.2.2.18 for disabling support for legacy binary formats. + The uselib system call, in particular, has no valid use in any libc6 or uclibc system in recent times. + This configuration is supported in Linux 3.15 and greater and thus should only be + disabled for such versions. + +```bash + CONFIG_USELIB=n +``` + +### Disable firmware auto-loading user mode helper + + The firmware auto loading helper, which is a utility executed by the + kernel on hotplug events requiring firmware, needs to be set setuid. + As a result of this, the helper utility is an attractive target for + attackers with control of physical ports on the device. + Disabling this configuration is supported in Linux 3.9 and greater. + +```bash + CONFIG_FW_LOADER_USER_HELPER=n +``` + +### Enable Kernel Panic on OOPS + + When fuzzing the kernel or attempting kernel exploits attackers are + likely to trigger kernel OOPSes. + Setting the behavior on OOPS to PANIC can impede their progress. + This configuration is supported in Linux 3.5 and greater and thus should only be enabled for such versions. + +```bash + CONFIG_PANIC_ON_OOPS=y +``` + +### Disable socket monitoring interface + + These monitors can be used to inspect shared file descriptors on Unix + Domain sockets or traffic on ‘localhost’ which is otherwise assumed to + be confidential. + The **CONFIG\_PACKET\_DIAG** configuration is supported in Linux 3.7 and greater and thus should only be disabled + for such versions. + The **CONFIG\_UNIX\_DIAG** configuration is + supported in Linux 3.3 and greater and thus should only be disabled + for such versions. + +```bash + CONFIG_PACKET_DIAG=n + CONFIG_UNIX_DIAG=n +``` + +### Disable BPF JIT + + The BPF JIT can be used to create kernel-payloads from firewall table + rules. + This configuration for is supported in + Linux 3.16 and greater and thus should only be disabled for such + versions. + +```bash + BPF_JIT=n +``` + +### Enable Enforced Module Signing + + This configuration is supported in Linux 3.7 and greater and thus + should only be enabled for such versions. + +```bash + CONFIG_MODULE_SIG_FORCE=y +``` + +### Disable all USB, PCMCIA (and other hotplug bus) drivers that aren’t needed + + To reduce the attack surface, the driver enumeration, probe, and + operation happen in the kernel. + The driver data is parsed by the kernel, so any logic bugs in these drivers can become kernel exploits. + +### Disable all file systems not needed + + To reduce the attack surface, file system data is parsed by the kernel + so any logic bugs in file system drivers can become kernel exploits. + +### Kernel Address Display Restriction + + When attackers try to develop "run anywhere" exploits for kernel + vulnerabilities, they frequently need to know the location of internal + kernel structures. + By treating kernel addresses as sensitive information, those locations are not visible to regular local users. + + /proc/sys/kernel/kptr\_restrict is set to "1" to block the reporting + of known kernel address leaks. + + Additionally, various files and directories should be readable only by + the root user: /boot/vmlinuz\*, /boot/System.map\*, + /sys/kernel/debug/, /proc/slabinfo + +### DMESG Restrictions + + When attackers try to develop "run anywhere" exploits for + vulnerabilties, they frequently will use dmesg output. + By treating dmesg output as sensitive information, this output is not available to + the attacker. + + /proc/sys/kernel/dmesg\_restrict can be set to "1" to treat dmesg + output as sensitive. + +Enable the below compiler and linker options when building user-space +applications to avoid stack smashing, buffer overflow attacks. + +### Stack Smashing Attacks + + **-fstack-protector-all** + + Emit extra code to check for buffer overflows, such as stack smashing + attacks + +### Position Independent Executables + + **-pie –fpic** + + Produce a position independent executable on targets which supports + it. + +### Detect Buffer Overflows + + **-D\_FORTIFY\_SOURCE=2** + + Helps detect some buffer overflow errors. + +### Prevent Overwrite Attacks + + **–z,relro** + + This linking option helps during program load, several ELF memory + sections need to be written by the linker, but can be turned read-only + before turning over control to the program. This prevents some Global + Offset Table GOT overwrite attacks, or in the dtors section of the ELF + binary. + + **-z,now** + +During program load, all dynamic symbols are resolved, allowing for the +complete GOT to be marked read-only (due to -z relro above). This +prevents GOT overwrite attacks. For very large application, this can +incur some performance loss during initial load while symbols are +resolved, but this shouldn't be an issue for daemons. + +### Library linking + + **–static** + +It is recommended that dynamic linking should not be allowed. This will +avoid user from replacing a library with malicious library. All libraries +should be linked statically. + +## Removal or Non-Inclusion of Utilities + +Table below lists utilities that are typically present in an embedded +device, along with the normal path of each utility. The table has +information about whether a utility shall be included or excluded from +respective environment. The values “INCLUDE” here means to include the +utility in the environment and “EXCLUDE” means to exclude it from the +respective environment. + +| **Utility Name** | **Location** | **Debug Environment** | **Production Environment** | +|-------------------|-------------------------------------------|------------------------|------------------------------| +| Strace | /bin/trace | INCLUDE | EXCLUDE | +| Klogd | /sbin/klogd | INCLUDE | EXCLUDE | +| Syslogd(logger) | /bin/logger | INCLUDE | EXCLUDE | +| Gdbserver | /bin/gdbserver | INCLUDE | EXCLUDE | +| Dropbear | Remove “dropbear” from ‘/etc/init.d/rcs’ | EXCLUDE | EXCLUDE | +| SSH | NA | INCLUDE | EXCLUDE | +| Editors (vi) | /bin/vi | INCLUDE | EXCLUDE | +| Dmesg | /bin/dmesg | INCLUDE | EXCLUDE | +| UART | /proc/tty/driver/ | INCLUDE | EXCLUDE | +| Hexdump | /bin/hexdump | INCLUDE | EXCLUDE | +| Dnsdomainname | /bin/dnsdomainname | EXCLUDE | EXCLUDE | +| Hostname | /bin/hostname | INCLUDE | EXCLUDE | +| Pmap | /bin/pmap | INCLUDE | EXCLUDE | +| su | /bin/su | INCLUDE | EXCLUDE | +| Which | /bin/which | INCLUDE | EXCLUDE | +| Who and whoami | /bin/whoami | INCLUDE | EXCLUDE | +| ps | /bin/ps | INCLUDE | EXCLUDE | +| lsmod | /sbin/lsmod | INCLUDE | EXCLUDE | +| install | /bin/install | INCLUDE | EXCLUDE | +| logger | /bin/logger | INCLUDE | EXCLUDE | +| ps | /bin/ps | INCLUDE | EXCLUDE | +| rpm | /bin/rpm | INCLUDE | EXCLUDE | +| Iostat | /bin/iostat | INCLUDE | EXCLUDE | +| find | /bin/find | INCLUDE | EXCLUDE | +| Chgrp | /bin/chgrp | INCLUDE | EXCLUDE | +| Chmod | /bin/chmod | INCLUDE | EXCLUDE | +| Chown | /bin/chown | INCLUDE | EXCLUDE | +| killall | /bin/killall | INCLUDE | EXCLUDE | +| top | /bin/top | INCLUDE | EXCLUDE | +| stbhotplug | /sbin/stbhotplug | INCLUDE | EXCLUDE | + +Note: The following Unix/Linux utilities shall be permitted as they are +often used in the start-up scripts and for USB logging. If any of these +utilities are not required by the device then those should be removed. + + **sed, awk, cut, df, dmesg, echo, fdisk, grep, mkdir, mount (vfat), + printf, tail, tee, test (directory), test (file)** + +## Root Access + +The main applications, those that provide the principal functionality of +the embedded device, **should not execute** with root identity or any +capability. + +If the main application are allowed to execute at any capability, +then the entire system is at the mercy of the said application’s good +behaviour. Problems arise when an application is compromised and able to +execute commands which could consistently and persistently compromise +the system by implanting rogue applications. + +It is suggested that the middleware and the UI should run in a context +on a user with no capability and all persistent resources should be +maintained without any capability. + +One way to ensure this is by implementing a server-client paradigm. +Services provided by the system’s drivers can be shared this way. The +other advantage of this approach is that multiple applications can share +the same resources at the same time. + +Root access **should not be allowed** for the following utilities: + +``` + login + su + ssh + scp + sftp +``` + +Root access **should not be allowed** for the console device. The +development environment should allow users to login with pre-created +user accounts. + +Switching to elevated privileges shall be allowed in the development +environment via sudo. + +## Network Hardening + +### Disable IPv4 Forwarding + + The net.ipv4.ip\_forward sysctl setting controls if IP forwarding is + allowed or not on the System. Unless the system is used as a router or + gateway, IPv4 forwarding should be disabled. + +### Disable IP Source Routing + + Disable IP source routing on all interfaces through the + net.ipv4.conf.\*.accept\_source\_route = 0 setting. + + IP source routing would allow a remote user (the sender) to specify + the route that the packet should take, rather than use the (default) + routing tables used by the routers between the sender and the + destination. This could be used to spoof IP addresses and still get + the replies (rather than sending the replies to the real owner of the + IP address). + +### Disable ICMP + + Use of ICMP, especially ping, shall be avoided. This is a common way + of gaining access to a system. + +#### Disable ICMP Redirects + + Set net.ipv4.conf.\*.accept\_redirects=0 to disable ICMP redirect + support on the interfaces. + + ICMP redirect messages are used by routers to inform hosts to use a + different gateway than the one used. These packets should only be sent + by the gateway of the system. In managed and embedded devices the + gateway is controlled and any changes should be controlled. + + Allowing ICMP redirect messages would allow for "remote" updating of + the routing table, which could allow an attacker to get all packets + sent to the outside first rather than the packets immediately going to + the real gateway. + +#### Ignore ICMP Echo Broadcasts + + When net.ipv4.icmp\_echo\_ignore\_broadcasts=1 is set, then your + system will not reply to broadcast “ping” requests. + +#### Ignore ICMP Bogus Error Responses + + When an invalid response is given to broadcast frames (which occurs + sometimes in erroneous routers), the Linux kernel will by default log + this event. These can be disabled by setting + throughnet.ipv4.icmp\_ignore\_bogus\_error\_responses to 1. + +### Ignore all broadcast message + + All the IP packets that come on the address “255.255.255.255” shall be + ignored. This can be done through the iptables rules. + +### Disable IPV6 + + If there are no plans of using IPV6, it is a good practice to disable + this support as it will reduce the size of the kernel TCP/IP stack. + +### Enable TCP SYN Cookie Protection + + One way of denial of service (DoS) attack against a service would be + to flood the server with SYNrequests (the TCP packet that starts a + handshake for a connection). Such a flood can lead to a service + disruption as the connection state handling will consume significant + resources. + + By enabling net.ipv4.tcp\_syncookies, the Linux kernel will change its + handshake behavior when its SYN backlog queue overflows: it replies to + SYN requests with the appropriate SYN+ACK reply, but it does not store + the connection in its backlog queue. + + +# Validation + +## Hardened System + +### Image Security Analysis Framework (ISAFW) + +**meta-security-isafw** is an OE layer that allows enabling the Image +Security Analysis Framework (isafw) for your image builds. + +The primary purpose of isafw is to provide an extensible +framework for analysing different security aspects of images +during the build process. + +The isafw project itself can be found at + https://github.com/01org/isafw + +This layer can be added to your builds to produce an analysis report, +including a kernel config analysis. + +### Usage + +In order to enable the isafw during the image build, please add +the following line to your build/conf/local.conf file: + +```python +INHERIT += "isafw" +``` |