Linux Kernel Security Researcher手把手教你加固内核安全配置

sunsili

Linux Kernel Security Researcher手把手教你加固内核安全配置

作者简介：许庆伟：龙蜥社区eBPF技术探索SIG组 Maintainer & Linux Kernel Security ResearcherCSDN博客：内核功守道


一、知识背景

正如Linus Torvalds曾经说过的，大多数安全问题都是bug造成的，而bug又是软件开发过程的一部分，是软件就有bug。至于是安全还是非安全漏洞BUG，内核社区的做法就是尽可能多的测试，找出更多潜在漏洞这样近似于黑名单的做法。Greg Kroah-Hartman说：“一旦我们修复了它，我们就将它放到我们的栈分析规则中，以便于以后不再重新出现这个bug。”如果没有2015年11月5号华盛顿邮报的一篇关于内核安全性的爆炸性专题报道《Net of insecurity the kernel of the argument》，内核社区应该仍会固守“A bug is bug”的理念（虽然如今也没有改变太多）。这篇文章狠狠的批评了内核社区对内核安全的态度，批评Linux “没有一个系统性的机制能在黑客之前发现和解决安全问题，或引入更新的防御技术”，“甚至Linux内核开发社区都没有一个首席安全官”等等。

我们都知道内核社区的传统就是相对安全性更侧重于性能和功能（这也是各大厂商最关注的部分），在需要牺牲性能来改善内核安全性时并不愿意折衷处理。其实从另一个角度来看，也不是内核社区不想合入有用的安全Patch，从LKML里面关于LSM或者其他Security相关的订阅人数、世界上独立的内核安全公司数量来看，除了一些内核安全机制有相应大公司或大社区维护（SELinux (NSA)、AppArmor (OpenSuSE/Ubuntu)、PaX / grsecurity (Spender)），以及PaX / grsecurity和内核社区的历史渊源，所以在全球范围内，真实有效的内核安全开发者是少之又少。

再加上内核代码提交走的流程比较繁琐，应用到具体内核版本上，又存在周期长以及版本适配的问题，如下图，所以导致内核在安全方面发展的速度明显慢于其他模块。

• 一个Linux内核漏洞的修复从Upstream到发行版内核（生产环境）的链条过长，因为实际情况是没有人会真正意义上使用"Upstream"的内核；
• 内核稳定分支以及发行版社区难以跟进每一个安全修复的分析，回归测试以及防御手段，甚至会出现漏掉的情况；
• Linux内核社区坚持"Security through obscurity"哲学，这意味着内核社区从来不主动申请CVE漏洞编号，即使如此，2021年1月到8月，有CVE编号的内核漏洞超过110个
• 漏洞军火商有自己的生态，他们并不关心是否有CVE的存在而只关注漏洞的成因以及漏洞利用的方法
  
  
  
  

随着智能化、数字化、云化的飞速发展，全球基于Linux系统的设备数以百亿计，而这些设备的安全保障主要取决于主线内核的安全性和健壮性。当某一内核LTS版本被发有漏洞，这样相关的机器都会面临被攻破利用的局面，损失难以估计。

• 
  

                                    Critical & High CVE lifetimes

基于以上历史原因，内核自防护项目KSPP（Kernel Self Protection Project）应运而生。KSPP是由Linux基金会旗下的CII（基础架构联盟）管理，其吸纳了来自诸多大厂商（Google, RedHat,Intel,ARM等）的工程师进行联合工作，旨在缓解Linux内核自身安全缺陷，增强对内核漏洞的防御，主要参考了主要工作是参考PaX / grsecurity的实现来移植或者重新实现类似的功能然后推进到Linux内核主线。

第一个加固内核安全的Patch合并到了主线Linux 4.6上，自此，KSPP开始了自己的使命，不限于对以下几点，对内核安全性做了增强和优化：

• 缩小攻击面
• 限制内核的内存使用权限
• 只读数据和可执行代码不可写
• 函数指针和重要变量不可写
• User space和Kernel space内存分离
• 过滤无用系统调用
• 内存完整性
• KASLR
  

二、加固内核Config文件配置

从KSPP项目角度出发，以上所有内核安全方案的基础，都在于对内核Config文件的加固配置。下面从通用配置、GCC配置、命令行调试配置、ARM和X86的32位以及64位体系架构，这几个涵盖面最广的角度来分别讲解具体推荐配置，这些配置不仅用于加固内核安全，更可以用在内核稳定性和性能优化上，具体大家可以在实验环境下验证效果。

• 内核通用配置
• GCC编译器
• 命令行调试配置
• X86_32
• X86_64
• ARM
• ARM64
  

三、内核通用配置

#Debug开关，以便调试
CONFIG_BUG=y#内核页表安全配置
CONFIG_DEBUG_KERNEL=y (4.11版本之前)
CONFIG_DEBUG_RODATA=y (4.11版本)
CONFIG_STRICT_KERNEL_RWX=y (4.11至最新版本)#报告危险内存权限情况（注：不是所有平台都适用）
CONFIG_DEBUG_WX=y#启用直接物理内存访问
CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y#SYN 防护
CONFIG_SYN_COOKIES=y#多重加固验证常见的结构体异常
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_SG=y
CONFIG_BUG_ON_DATA_CORRUPTION=y
CONFIG_SCHED_STACK_END_CHECK=y#使能seccomp BPF
CONFIG_SECCOMP=y
CONFIG_SECCOMP_FILTER=y#使能用户层Ptrace保护机制
CONFIG_SECURITY=y
CONFIG_SECURITY_YAMA=y#使能usercopy边界检查，并禁止fallback，以获得完整的白名单执行CONFIG_HARDENED_USERCOPY=y
#CONFIG_HARDENED_USERCOPY_FALLBACK is not set
#CONFIG_HARDENED_USERCOPY_PAGESPAN is not set#随机分配空闲列表，加固meatadata
CONFIG_SLAB_FREELIST_RANDOM=y
CONFIG_SLAB_FREELIST_HARDENED=y#High-order页分配空闲列表
CONFIG_SHUFFLE_PAGE_ALLOCATOR=y#使能Slub分配器检查
CONFIG_SLUB_DEBUG=y#当Higher-level分配的内存释放后立即擦除，需要使能page_poison=1
CONFIG_PAGE_POISONING=y
CONFIG_PAGE_POISONING_NO_SANITY=y
CONFIG_PAGE_POISONING_ZERO=y#使能内核栈保护
CONFIG_VMAP_STACK=y#使能引用计数检查
CONFIG_REFCOUNT_FULL=y#在构建时和运行时检查str*()和mem*()函数中可能溢出结构的内存拷贝
CONFIG_FORTIFY_SOURCE=y#避免通过dmesg暴露内存地址
CONFIG_SECURITY_DMESG_RESTRICT=y#使能系统调用入口上的随机内核栈偏移量计算（5.13版本后）
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y#使能内存溢出检测，类似于KASAN，但是开销几乎为0，可以全环境复现问题时是使用
CONFIG_KFENCE=y#使能编译警告，便于调试 (5.15版本后)
CONFIG_WERROR=y#强制IOMMU TLB失效，使设备永远无法访问过时的数据内容CONFIG_IOMMU_DEFAULT_DMA_STRICT=y#在退出函数时，擦除所有调用者使用的寄存器痕迹，以防止ROP攻击CONFIG_ZERO_CALL_USED_REGS=y#禁止物理内存直接写入
#CONFIG_ACPI_CUSTOM_METHOD is not set#禁止基于brk的ASLR
#CONFIG_COMPAT_BRK is not set#禁止内核内存直接写入
#CONFIG_DEVKMEM is not set#禁止内核Kcore布局图
#CONFIG_PROC_KCORE is not set#禁止VDSO ASLR
#CONFIG_COMPAT_VDSO is not set#建议4.1版本之前关闭此选项，阻断堆内存攻击
#CONFIG_INET_DIAG is not set#关闭传统PTY接口
#CONFIG_LEGACY_PTYS is not set#使能SELinux运行时调整功能
#CONFIG_SECURITY_SELINUX_DISABLE is not set#出现内核oops时，立即重启
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_TIMEOUT=-1#关闭Root用户通过加载模块来修改内核内存
#CONFIG_MODULES is not set#如果的确需要使用Root权限来操作内核，在使能CONFIG_MODULE=y后，建议打开如下配置：CONFIG_DEBUG_SET_MODULE_RONX=y
CONFIG_STRICT_MODULE_RWX=y
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH=“sha512”
CONFIG_MODULE_SIG_KEY=“certs/signing_key.pem”

四、GCC
#使能GCC Plugins
CONFIG_GCC_PLUGINS=y#使能-fstack-protector-strong (gcc 4.9+) 以全范围覆盖检测Stack Canary
#内核4.18版本之前，如下配置：
#CONFIG_CC_STACKPROTECTOR=y
#CONFIG_CC_STACKPROTECTOR_STRONG=y#内核4.18版本之后，如下配置：
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y#使能在函数入口初始化所有堆栈变量，要求Clang和GCC 12版本以上CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y（GCC 12前）
CONFIG_INIT_STACK_ALL_ZERO=y#系统启动时收集更多的entropy信息
CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y#强制所有结构体在传递给其他函数之前进行初始化
CONFIG_GCC_PLUGIN_STRUCTLEAK=y
CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y#系统调用推出后擦除堆栈信息，减少堆栈内旧数据的生命周期CONFIG_GCC_PLUGIN_STACKLEAK=y#随机化系统结构的布局。这可能会对性能产生巨大的影响，所以请谨慎使用或使用
#CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE=y
CONFIG_GCC_PLUGIN_RANDSTRUCT=y

五、X86_64
#禁止分配内存起始阶段的64K内地址
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536#禁止MSR寄存器写权限
#CONFIG_X86_MSR is not set#使能随机分配内核和内存地址
CONFIG_RANDOMIZE_BASE=y
CONFIG_RANDOMIZE_MEMORY=y#Libc不再需要用户空间中的固定位置映射
CONFIG_LEGACY_VSYSCALL_NONE=y#使能内核页表隔离机制，以删除整个缓存计时侧通道类
CONFIG_PAGE_TABLE_ISOLATION=y#缩小暴露的攻击面
#CONFIG_IA32_EMULATION is not set
#CONFIG_X86_X32 is not set
#CONFIG_MODIFY_LDT_SYSCALL is not set#完全删除vsycall，以避免它成为任何类型的固定位置的ROP目标。
vsyscall=none
六、X86_32

#32-bit 内核上, 使能PAE#CONFIG_M486 is not set
#CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_X86_PAE=y#禁止分配内存起始阶段的64K内地址
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536#禁止MSR寄存器写权限
#CONFIG_X86_MSR is not set#使能随机分配内核地址
CONFIG_RANDOMIZE_BASE=y#使能内核页表隔离机制，以删除整个缓存计时侧通道类
CONFIG_PAGE_TABLE_ISOLATION=y#禁止16位程序模拟和相关的LDT操作
#CONFIG_MODIFY_LDT_SYSCALL is not set

七、ARM64

#禁止分配内存起始阶段的32K内地址，不是64K的原因是因为ARM加载器需要使用这段地址
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768#使能随机分配内核地址
CONFIG_RANDOMIZE_BASE=y#使能PAN模拟器.
CONFIG_ARM64_SW_TTBR0_PAN=y#使能内核页表隔离机制，以删除整个缓存计时侧通道类
CONFIG_UNMAP_KERNEL_AT_EL0=y

八、Arm  
#禁止分配内存起始阶段的32K内地址，不是64K的原因是因为ARM加载器需要使用这段地址
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768#最大化用户空间内存和ASLR
CONFIG_VMSPLIT_3G=y#对于老的Qualcomm内核版本，如下配置
CONFIG_STRICT_MEMORY_RWX=y#使能PXN/PAN模拟器
CONFIG_CPU_SW_DOMAIN_PAN=y#禁止陈旧接口，缩减攻击面
#CONFIG_OABI_COMPAT is not set

九、进程命令行调试配置

#擦除Slab和页分配的内存（5.3版本后）
init_on_alloc=1
init_on_free=1#使能系统调用入口上的随机内核栈偏移量计算（5.13版本后）
randomize_kstack_offset=on#禁用slab合并，使得许多堆溢出攻击更加困难
slab_nomerge#始终启用内核页表隔离，即使CPU声称它对Meltdown是安全的
pti=on#预防L1TF
nosmt#使能SLUB redzoning和健康检查
slub_debug=ZF#使能Slab/Slub分配器的内存溢出检测功能，需在内核5.3后版本上，使能CONFIG_SLUB_DEBUG=y
slub_debug=P#使能伙伴系统分配器的内存溢出检测功能，需要在内核5.3版本上，使能CONFIG_PAGE_POISONING=y
page_poison=1#强制IOMMU TLB失效，使设备永远无法访问过时的数据内容
iommu.passthrough=0 iommu.strict=1

十、结论
内核安全问题，牵一发而动全身，尤其是在配置方面，所以如果有的时候在稳定性或者性能优化上卡住，不妨从内核配置的角度，结合上文的详细说明，换个角度来分析问题，可能会有更好的收获。这篇文章着重从内核安全配置的角度来分析了KSPP，在LSM机制、漏洞利用分析、栈溢出攻击等方面会有真实利用场景，后续会逐步更新相关文章。