hardened-kernel

From Kicksecure
Jump to navigation Jump to search

hardened-kernel

Developers only! Warning: This is for developers-only!

Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.

Overview[edit]

hardened-kernelarchive.org attempts to increase computer security.

It is based on Linuxarchive.org.

Is consists of a hardened kernel configuration and hardening patches provided by the linux-hardenedarchive.org project.

It is currently only tested in Kicksecure. Therefore hardened-kernel will likely work in Debianarchive.org too.

There are two kernel configs, hardened-vm-kernelarchive.org and hardened-host-kernelarchive.org. hardened-vm-kernel is designed specifically for virtual machines (VMs) and hardened-host-kernel is designed for hosts.

Both configs try to have as many hardening options enabled as possible and have little attack surface. hardened-vm-kernel only has support for VMs and all other hardware options are disabled to reduce attack surface and compile time.

During installation of hardened-vm-kernel, it compiles the kernel on your own machine and does not use a pre-compiled kernel. This ensures the kernel symbols in the compiled image are completely unique which makes it far harder for kernel exploits. This is possible due to hardened-vm-kernel having only VM config options enabled which drastically reduces compile time.

A development goal is that during installation of hardened-host-kernel, the kernel is not compiled on your machine but uses a pre-compiled kernel. This is because the host kernel needs most hardware options enabled to support most devices which makes compilation take a very long time. This will be probably configureable, i.e. you will be able to opt-in to compile the host kernel locally too.

The VM kernel is more secure than the host kernel due to having less attack surface and not being pre-compiled but if you want more security for the host, it is recommended to edit the hardened host config, enable only the hardware options you need and compile the kernel yourself. This makes the security of the host and VM kernel comparable.

These kernels use the linux-hardened patch for further hardening. Custom hardening patches should be sent there.

Both configs were based on the default Debian config.

Improvements[edit]

Here is a list of the improvements of the config. This may not be complete but has the bulk of the features.

Attack surface reduction[edit]

hardened-kernel disables numerous options within the kernel in an attempt to minimize the exposed attack surface.

Many features within the kernel are designed to allow the root user to modify kernel code. This is unacceptable within our threat model. As such, features permitting this level of access are disabled:

  • CONFIG_DEVMEM=n - /dev/mem. [1] This can be restricted via CONFIG_STRICT_DEVMEM and CONFIG_IO_STRICT_DEVMEM but it is best to disable it altogether.
  • CONFIG_DEVKMEM=n - /dev/kmem. [2]
  • CONFIG_DEVPORT=n - /dev/port. [3]
  • CONFIG_LIVEPATCH=n - Livepatching. [4]
  • CONFIG_KEXEC=n - kexec. [5]
  • CONFIG_X86_MSR=n - CPU MSRs. [6]
  • CONFIG_ACPI_TABLE_UPGRADE=n - ACPI table upgrading. [7]
  • CONFIG_HIBERNATION=n - Hibernation. The kernel image can be replaced during hibernation.

Note that we enable CONFIG_KPROBES, but we still use a minimal configuration to avoid exposing attack surface to user space as other security functionality requires this, including LKRG and tirdad. [8]

However, despite these efforts, the following remaining kernel features have been identified to still be able to modify or extract sensitive data from the kernel:

  • efivar_ssdt_load (only applicable for the host kernel).
  • perf_event_open().
  • iopl() and ioperm().
  • TIOCSSERIAL.
  • Direct PCI BAR access.
  • Replacement of the PCMCIA Card Information Structure.
  • Certain module parameters.

The above features can only be disabled with custom kernel patches which are not included yet.

In order to further reduce attack surface, hardened-kernel also disables dangerous features that have resulted in kernel vulnerabilities or can otherwise aid exploitation:

  • CONFIG_BPF_SYSCALL=n - The bpf() syscall can be abused to read arbitrary kernel memory through functions such as bpf_probe_read() [9] and has caused countless kernel vulnerabilities. [10] [11] [12] [13]
  • CONFIG_SLAB_MERGE_DEFAULT=n - Disabling slab merging significantly increases the difficulty of heap exploitation by preventing overwriting objects from merged caches [14] and by making it harder to influence slab cache layout. [15]
  • CONFIG_USERFAULTFD=n - The userfaultfd() syscall is often abused to exploit use-after-free flaws. [16] [17]
  • CONFIG_LEGACY_VSYSCALL_NONE=y, CONFIG_X86_VSYSCALL_EMULATION=n - vsyscalls are obsolete, are at fixed addresses and thus, are a potential target for ROP.
  • CONFIG_VIDEO_VIVID=n - The vivid driver is only required for testing and has been the cause of multiple vulnerabilities. [18]
  • CONFIG_BINFMT_MISC=n - binfmt_misc. We don't need custom binary formats and they only add attack surface.
  • CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n - Legacy nouveau contexts aren't needed anymore and contain security holes. [19]
  • CONFIG_INET_DIAG=n - The INET socket monitoring interface has aided heap memory attacks in the past.
  • CONFIG_COREDUMP=n, CONFIG_CRASH_DUMP=n - Core dumps and crash dumps can contain sensitive information.
  • CONFIG_USELIB=n - The uselib() is only used in older libc versions and is unnecessary. It has also been the cause of privilege escalation vulnerabilities in the past.
  • CONFIG_X86_X32=n, CONFIG_IA32_EMULATION=n - 32-bit support and IA32 emulation adds a lot of additional complexity to the kernel and doesn't receive much attention upstream so it's full of bugs. [20]
  • CONFIG_MODIFY_LDT_SYSCALL=n - The modify_ldt() syscall increases low-level kernel attack surface.
  • CONFIG_KSM=n - KSM can aid side-channel attacks. [21]
  • CONFIG_IP_DCCP=n, CONFIG_IP_SCTP=n, CONFIG_RDS=n, etc. - Many rare network protocols are disabled, including, DCCP, SCTP, RDS and more. These often cause critical vulnerabilities in the kernel and are generally unneeded.
  • CONFIG_FIREWIRE=n, CONFIG_THUNDERBOLT=n - FireWire and Thunderbolt can be abused for DMA attacks. [22] [23]
  • CONFIG_AIO=n - POSIX AIO is a niche and poorly designed feature that significantly increases the complexity of the kernel whilst receiving very little attention from developers. [24] [25] [26]
  • CONFIG_SYSFS_SYSCALL=n - The sysfs() syscall is deprecated.
  • CONFIG_PROC_KCORE - /proc/kcore exposes sensitive information about the current kernel which can be useful to an attacker.
  • CONFIG_DEBUG_FS=n - debugfs is a filesystem which contains a substantial amount of sensitive kernel information. [27]
  • CONFIG_NOTIFIER_ERROR_INJECTION=n - Notifier error injection allows userspace to inject artificial errors into kernel code. [28]
  • CONFIG_PROFILING=n - Profiling support can potentially allow user space to gather dangerous debugging information about the kernel.
  • CONFIG_PROC_PAGE_MONITOR=n - /proc page monitoring adds additional files to /proc, some of which leak sensitive memory information that could be useful to bypass ASLR.
  • CONFIG_LDISC_AUTOLOAD=n - This restricts loading line disciplines to the CAP_SYS_MODULE which prevents unprivileged attackers from loading vulnerable line disciplines to exploit. [29] [30]
  • CONFIG_RANDOM_TRUST_CPU=n - This distrusts the CPU for initial entropy as it cannot be audited to ensure that it provides high quality entropy. [31]
  • CONFIG_STAGING=n - Staging drivers are lower quality and are more likely to contain vulnerabilities.
  • CONFIG_IPV6=n - Tor currently doesn't have great support for IPv6 and as such, it is disabled in Kicksecure.

In addition, a wide variety of unused filesystems, partition types, unused LSMs (only AppArmor is enabled) and vulnerable, legacy drivers have been disabled.

Security features[edit]

hardened-kernel enables as many security features as it can:

  • CONFIG_DEBUG_SG=y, CONFIG_DEBUG_NOTIFIERS=y, CONFIG_DEBUG_CREDENTIALS=y, CONFIG_DEBUG_LIST=y, CONFIG_BUG_ON_DATA_CORRUPTION=y, CONFIG_SCHED_STACK_END_CHECK=y - Enables validation of commonly targeted structures (SG tables, notifier call chains, credential management, linked list manipulation).
  • CONFIG_DEBUG_VIRTUAL=y - Enables sanity checks in virtual to page code to prevent certain data corruption.
  • CONFIG_INTEL_IOMMU_DEFAULT_ON=y - Enables IOMMU by default to prevent DMA attacks. [32]
  • CONFIG_GCC_PLUGIN_STRUCTLEAK=y - STRUCTLEAK automatically initializes stack variables to zero to mitigate uninitialized memory vulnerabilities. [33] [34] We use STRUCTLEAK's strongest option (BYREF_ALL).
  • CONFIG_GCC_PLUGIN_RANDSTRUCT=y - RANDSTRUCT randomizes the layout of sensitive kernel structures. [35] [36] We do not weaken RANDSTRUCT with the RANDSTRUCT_PERFORMANCE option.
  • CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y - LATENT_ENTROPY gathers more entropy during boot.
  • CONFIG_RESET_ATTACK_MITIGATION=y - The reset attack mitigation prevents cold boot attacks by overwriting memory with zeroes upon shutdown but this requires firmware support. [37] [38]
  • CONFIG_CRYPTO_JITTERENTROPY=y, CONFIG_HW_RANDOM_INTEL=y, CONFIG_HW_RANDOM_AMD=y, etc. - Jitterentropy and various HWRNGs are built-in for better entropy.
  • CONFIG_MODULE_SIG_ALL=y, CONFIG_MODULE_SIG_HASH="sha512" - All kernel modules are signed during compilation and the strongest available hash function (SHA512) is used. However, signature verification is not yet enforced (see below).
  • CONFIG_PANIC_ON_OOPS=y - This causes the kernel to panic on oopses to thwart certain kernel exploits. This is only enabled for hardened-vm-kernel as it can break some host machines. Hosts are recommended to enable this feature via security-miscarchive.org instead.
  • CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x84 - The SysRq key is restricted to only allow SAK and shutdowns.

linux-hardened[edit]

linux-hardenedarchive.org is a patch for the Linux kernel that adds many useful hardening features:

  • Many ASLR improvements. [39]
  • Marks more data as read-only.
  • Adds writable function pointer detection.
  • Enables stricter sysctls by default although we set these with security-misc already.
  • Additional sanity checks.
  • Slab canaries.
  • Sanitizes slab and page allocations on free (for non-LTS kernels, it just uses init_on_{free,alloc} with some enhancements).
  • Verifies slab and page sanitization.
  • Restricts the TIOCSTI ioctl to CAP_SYS_ADMIN as it can be used to compromise many programs in the same session.
  • Disables unprivileged user namespaces as these expose significant kernel attack surface to unprivileged users.
  • Restricts device timing sidechannels to CAP_MKNOD.
  • Restricts all perf_event_open() use to CAP_SYS_ADMIN.
  • Makes the kernel BUG on more data corruption.
  • Adds the extra_latent_entropy kernel boot parameter to gather more entropy during boot.
  • Disables TCP simultaneous connect. This weakness allows an attacker to easily prevent a client from connecting to a known server so it should be disabled.

There are some additional features that we do not yet take advantage of however:

  • FORTIFY_SOURCE enhancements. These don't appear to be intended for production usage.
  • Extends init_on_free and init_on_alloc to slab caches with constructors. These aren't in our kernel version.
  • Hard-wires the legacy checkreqprot option to 0. We don't use SELinux.
  • Adds a sysctl to disable newly added USB devices (kernel.deny_new_usb). We don't make use of this yet.
  • Zero-fill uninitialized local variables. This requires clang compiler support and we use GCC.

Upcoming improvements of linux-hardened[edit]

We are contributing to linux-hardened and adding more hardening featuresarchive.org. These are not merged yet. This list documents these upcoming features:

  • Restricting module auto-loading to CAP_SYS_MODULE to prevent unprivileged attackers from auto-loading vulnerable modules to increase attack surface.
  • Restricting access to sysfs to root. Sysfs has been the cause of many vulnerabilities and info-leaks.
  • Further restricting perf_event_open() to deny even root from using it.
  • Trusted Path Execution.
  • Runtime read-only mount protection.
  • Restricting access to overly-permissive IPC objects.
  • Marking further data as read-only.

Unused options[edit]

There are some hardening options we don't use. This is a list of options we don't use and why.

  • CONFIG_STATIC_USERMODEHELPER=y - This would be great to enable but breaks boot as we do not yet have user space support. [40]
  • CONFIG_KALLSYMS=n - We set kptr_restrict so this won't make much difference except minor attack surface reduction.
  • CONFIG_MAGIC_SYSRQ=n - There are important features of SysRq we don't want to lose such as SAK. Instead, we restrict the SysRq key to only allow SAK and shutdowns.
  • CONFIG_BPF_JIT=n - We harden the BPF JIT compiler so this isn't as important but there has been some discussion on disabling this https://forums.whonix.org/t/should-the-bpf-jit-compiler-be-disabled/8475archive.org
  • CONFIG_MODULE_SIG_FORCE=y - Currently, this will break the Virtualbox Guest Additions, LKRG and Tirdad kernel modules but there is work on fixing this.
  • CONFIG_SLUB_DEBUG_ON=y - This gives no advantage over the slub_debug= boot parameter.
  • CONFIG_SECURITY_LOADPIN=y - We don't use loadpin so this option is pointless.
  • CONFIG_PAGE_POISONING=y - We use linux-hardened's CONFIG_PAGE_SANITIZE instead which is better and doesn't force debug bloat.
  • CONFIG_MODULES=n - We need kernel modules and restrict module loading as much as we can (with apparmor.d and in the future, enforcing signature verification and restricting auto-loading to root). This can be reconsidered once clang CFI is upstream as disabling module support improves CFI granularity.
  • CONFIG_USER_NS=n - This option is only a problem for unprivileged users and linux-hardened restricts these to root.

The following options are not enabled because they are not yet present in LTS kernels:

  • CONFIG_SHUFFLE_PAGE_ALLOCATOR=y
  • CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
  • CONFIG_INIT_ON_FREE_DEFAULT_ON=y
  • CONFIG_GCC_PLUGIN_STACKLEAK=y
  • CONFIG_SECURITY_LOCKDOWN_LSM=y
  • CONFIG_SECURITY_SAFESETID=y

The following options are not enabled because they require compiling the kernel with Clang rather than GCC:

  • CONFIG_INIT_STACK_ALL=y
  • CONFIG_LOCAL_INIT=y (linux-hardened)

There is currently not very much of an incentive to switch to Clang however, once exploit mitigations such as Control-Flow Integrity are upstreamed, this must be reconsidered. Switching to Clang now would likely result in a security decrease as we will lose GCC plugins such as RANDSTRUCT and STACKLEAK.

Disabled Devices[edit]

Both kernels disable some drivers that are unlikely to be used to cut attack surface. The drivers disabled are as follows:

  • All staging drivers:
    • CONFIG_RTL8192U - RealTek RTL8192U Wireless LAN NIC driver
    • CONFIG_RTL8192E - RealTek RTL8192E Wireless LAN NIC driver
    • CONFIG_RTL8723BS - RTL8723BS SDIO
    • Intel Compute Stick, the CHIP and many other Intel Atom and ARM based devices
    • R8712U
    • D-Link DWA-130
    • CONFIG_R8188EU
    • TP-Link TL-WN725N
    • CONFIG_R8822BE - Realtek RTL8822BE 802.11ac
    • CONFIG_RTS5208 - Realtek PCI-E Card Reader RTS5208/5288 support
    • CONFIG_PI433 - Pi433 - a 433MHz radio module for Raspberry Pi
    • some data acquisition device such as CONFIG_COMEDI
  • All industrial I/O support (CONFIG_IIO) is disabled. This includes things like humidity sensors, chemical sensors, light sensors, accelerometers etc. that don't really make sense on a usual desktop system.
  • All android support is disabled as these kernels aren't meant to be used on any mobile devices.
  • Infiniband support.
  • SMC-R, "sockets over RDMA", RDMA over Converged Ethernet (RoCE)

Project Status[edit]

Blockers before calling Kicksecure users for Testing[edit]

Blockers for Host Release[edit]

  • There is no pre-compiled hardened-host-kernel package yet.

Maintainability[edit]

  • Could use a script that helps contributors to easily update version numbers. (Using str_replace.)

Outreach[edit]

  • Few people know linux-hardenedarchive.org project. Even fewer know hardened-kernelarchive.org project. Places that previously discussed/used grsecurity are unaware of these project. Hence, few reviews/contributors.

List of All Tasks[edit]

Contribute[edit]

Since this is an Open Source / Free/Libre/Freedom Software project, development help is very much welcome!

Upstreaming[edit]

Seems unfortunately unlikely:

Forum Discussion[edit]

https://forums.whonix.org/t/kernel-recompilation-for-better-hardening/7598archive.org

References[edit]

  1. ↑ https://linux.die.net/man/4/memarchive.org
  2. ↑ https://linux.die.net/man/4/memarchive.org
  3. ↑ https://linux.die.net/man/4/memarchive.org
  4. ↑ https://www.kernel.org/doc/html/latest/livepatch/livepatch.htmlarchive.org
  5. ↑ https://en.wikipedia.org/wiki/Kexecarchive.org
  6. ↑ https://en.wikipedia.org/wiki/Model-specific_registerarchive.org
  7. ↑ https://www.kernel.org/doc/html/latest/admin-guide/acpi/initrd_table_override.htmlarchive.org
  8. ↑ https://github.com/GrapheneOS/os-issue-tracker/issues/408#issuecomment-820490823archive.org
  9. ↑ https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-can-bpf-overwrite-arbitrary-kernel-memoryarchive.org
  10. ↑ https://ricklarabee.blogspot.com/2018/07/ebpf-and-analysis-of-get-rekt-linux.htmlarchive.org
  11. ↑ https://nitter.net/bleidl/status/943714277403357185archive.org
  12. ↑ https://scannell.me/fuzzing-for-ebpf-jit-bugs-in-the-linux-kernel/archive.org
  13. ↑ https://www.thezdi.com/blog/2020/4/8/cve-2020-8835-linux-kernel-privilege-escalation-via-improper-ebpf-program-verificationarchive.org
  14. ↑ https://www.openwall.com/lists/kernel-hardening/2017/06/19/33archive.org
  15. ↑ https://www.openwall.com/lists/kernel-hardening/2017/06/20/10archive.org
  16. ↑ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cefdca0a86be517bc390fc4541e3674b8e7803b0archive.org
  17. ↑ https://duasynt.com/blog/linux-kernel-heap-sprayarchive.org
  18. ↑ https://www.openwall.com/lists/oss-security/2019/11/02/1archive.org
  19. ↑ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b30a43ac7132cdda833ac4b13dd1ebd35ace14b7archive.org
  20. ↑ https://seclists.org/oss-sec/2019/q4/98archive.org
  21. ↑ https://www.whonix.org/wiki/KVM#KSMarchive.org
  22. ↑ https://en.wikipedia.org/wiki/IEEE_1394#Security_issuesarchive.org
  23. ↑ https://en.wikipedia.org/wiki/Thunderbolt_(interface)#Security_vulnerabilitiesarchive.org
  24. ↑ https://web.archive.org/web/20190524021219/https://github.com/AndroidHardeningArchive/documentation/blob/master/technical_overview.md#attack-surface-reductionarchive.org
  25. ↑ https://lwn.net/Articles/671649/archive.org
  26. ↑ https://lwn.net/Articles/671657/archive.org
  27. ↑ https://lkml.org/lkml/2020/7/16/122archive.org
  28. ↑ https://www.kernel.org/doc/html/latest/fault-injection/notifier-error-inject.htmlarchive.org
  29. ↑ https://lkml.org/lkml/2019/4/15/890archive.org
  30. ↑ https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.htmlarchive.org
  31. ↑ https://github.com/Kicksecure/security-misc/blob/master/etc/default/grub.d/40_distrust_cpu.cfgarchive.org
  32. ↑ https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unitarchive.org
  33. ↑ https://github.com/torvalds/linux/blob/f0fe00d4972a8cd4b98cc2c29758615e4d51cdfe/security/Kconfig.hardening#L4-L18archive.org
  34. ↑ https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Forcibly_initialize_local_variables_copied_to_userlandarchive.org
  35. ↑ https://github.com/torvalds/linux/blob/e994cc240a3b75744c33ca9b8d74f71f0fcd8852/scripts/gcc-plugins/Kconfig#L63-L90archive.org
  36. ↑ https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Randomize_layout_of_sensitive_kernel_structuresarchive.org
  37. ↑ https://lwn.net/Articles/730006/archive.org
  38. ↑ https://www.trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdfarchive.org
  39. ↑ https://gist.github.com/thestinger/b43b460cfccfade51b5a2220a0550c35archive.org
  40. ↑ We could use something similar to https://github.com/tych0/huldufolkarchive.org in the future.
Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Hardened-kernel&oldid=84655"