萬字長文 | 手把手教你加固內核安全配置
[導讀]正如Linus Torvalds曾經(jīng)說過的，大多數(shù)安全問題都是bug造成的，而bug又是軟件開發(fā)過程的一部分，是軟件就有bug。至于是安全還是非安全漏洞BUG，內核社區(qū)的做法就是盡可能多的測試，找出更多潛在漏洞這樣近似于黑名單的做法。Greg Kroah-Hartman說：“一旦我們修復了它，我們就將它放到我們的棧分析規(guī)則中，以便于以后不再重新出現(xiàn)這個bug。”如果沒有2015年11月5號華盛頓郵報的一篇關于內核安全性的爆炸性專題報道《Net of insecurity the kernel of the argument》，內核社區(qū)應該仍會固守“A bug is bug”的理念（雖然如今也沒有改變太多）。這篇文章狠狠的批評了內核社區(qū)對內核安全的態(tài)度，批評Linux “沒有一個系統(tǒng)性的機制能在黑客之前發(fā)現(xiàn)和解決安全問題，或引入更新的防御技術”，“甚至Linux內核開發(fā)社區(qū)都沒有一個首席安全官”等等。
一、知識背景
正如Linus Torvalds曾經(jīng)說過的，大多數(shù)安全問題都是bug造成的，而bug又是軟件開發(fā)過程的一部分，是軟件就有bug。至于是安全還是非安全漏洞BUG，內核社區(qū)的做法就是盡可能多的測試，找出更多潛在漏洞這樣近似于黑名單的做法。Greg Kroah-Hartman說：“一旦我們修復了它，我們就將它放到我們的棧分析規(guī)則中，以便于以后不再重新出現(xiàn)這個bug。”如果沒有2015年11月5號華盛頓郵報的一篇關于內核安全性的爆炸性專題報道《Net of insecurity the kernel of the argument》，內核社區(qū)應該仍會固守“A bug is bug”的理念（雖然如今也沒有改變太多）。這篇文章狠狠的批評了內核社區(qū)對內核安全的態(tài)度，批評Linux “沒有一個系統(tǒng)性的機制能在黑客之前發(fā)現(xiàn)和解決安全問題，或引入更新的防御技術”，“甚至Linux內核開發(fā)社區(qū)都沒有一個首席安全官”等等。
我們都知道內核社區(qū)的傳統(tǒng)就是相對安全性更側重于性能和功能（這也是各大廠商最關注的部分），在需要犧牲性能來改善內核安全性時并不愿意折衷處理。其實從另一個角度來看，也不是內核社區(qū)不想合入有用的安全Patch，從LKML里面關于LSM或者其他Security相關的訂閱人數(shù)、世界上獨立的內核安全公司數(shù)量來看，除了一些內核安全機制有相應大公司或大社區(qū)維護（SELinux (NSA)、AppArmor (OpenSuSE/Ubuntu)、PaX / grsecurity (Spender)），以及PaX / grsecurity和內核社區(qū)的歷史淵源，所以在全球范圍內，真實有效的內核安全開發(fā)者是少之又少。
再加上內核代碼提交走的流程比較繁瑣，應用到具體內核版本上，又存在周期長以及版本適配的問題，如下圖，所以導致內核在安全方面發(fā)展的速度明顯慢于其他模塊。
- 一個Linux內核漏洞的修復從Upstream到發(fā)行版內核（生產環(huán)境）的鏈條過長，因為實際情況是沒有人會真正意義上使用"Upstream"的內核；
- 內核穩(wěn)定分支以及發(fā)行版社區(qū)難以跟進每一個安全修復的分析，回歸測試以及防御手段，甚至會出現(xiàn)漏掉的情況；
- Linux內核社區(qū)堅持"Security through obscurity"哲學，這意味著內核社區(qū)從來不主動申請CVE漏洞編號，即使如此，2021年1月到8月，有CVE編號的內核漏洞超過110個
-
漏洞軍火商有自己的生態(tài)，他們并不關心是否有CVE的存在而只關注漏洞的成因以及漏洞利用的方法
Critical & High CVE lifetimes
基于以上歷史原因，內核自防護項目KSPP（Kernel Self Protection Project）應運而生。KSPP是由Linux基金會旗下的CII（基礎架構聯(lián)盟）管理，其吸納了來自諸多大廠商（Google, RedHat,Intel,ARM等）的工程師進行聯(lián)合工作，旨在緩解Linux內核自身安全缺陷，增強對內核漏洞的防御，主要參考了主要工作是參考PaX / grsecurity的實現(xiàn)來移植或者重新實現(xiàn)類似的功能然后推進到Linux內核主線。
第一個加固內核安全的Patch合并到了主線Linux 4.6上，自此，KSPP開始了自己的使命，不限于對以下幾點，對內核安全性做了增強和優(yōu)化：
- 縮小攻擊面
- 限制內核的內存使用權限
- 只讀數(shù)據(jù)和可執(zhí)行代碼不可寫
- 函數(shù)指針和重要變量不可寫
- User space和Kernel space內存分離
- 過濾無用系統(tǒng)調用
- 內存完整性
- KASLR
二、加固內核Config文件配置
從KSPP項目角度出發(fā)，以上所有內核安全方案的基礎，都在于對內核Config文件的加固配置。下面從通用配置、GCC配置、命令行調試配置、ARM和X86的32位以及64位體系架構，這幾個涵蓋面最廣的角度來分別講解具體推薦配置，這些配置不僅用于加固內核安全，更可以用在內核穩(wěn)定性和性能優(yōu)化上，具體大家可以在實驗環(huán)境下驗證效果。
- 內核通用配置
- 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，以獲得完整的白名單執(zhí)行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#使能引用計數(shù)檢查
CONFIG_REFCOUNT_FULL=y#在構建時和運行時檢查str*()和mem*()函數(shù)中可能溢出結構的內存拷貝
CONFIG_FORTIFY_SOURCE=y#避免通過dmesg暴露內存地址
CONFIG_SECURITY_DMESG_RESTRICT=y#使能系統(tǒng)調用入口上的隨機內核棧偏移量計算（5.13版本后）
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y#使能內存溢出檢測，類似于KASAN，但是開銷幾乎為0，可以全環(huán)境復現(xiàn)問題時是使用
CONFIG_KFENCE=y#使能編譯警告，便于調試 (5.15版本后)
CONFIG_WERROR=y#強制IOMMU TLB失效，使設備永遠無法訪問過時的數(shù)據(jù)內容CONFIG_IOMMU_DEFAULT_DMA_STRICT=y#在退出函數(shù)時，擦除所有調用者使用的寄存器痕跡，以防止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#關閉傳統(tǒng)PTY接口
#CONFIG_LEGACY_PTYS is not set#使能SELinux運行時調整功能
#CONFIG_SECURITY_SELINUX_DISABLE is not set#出現(xiàn)內核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#使能在函數(shù)入口初始化所有堆棧變量，要求Clang和GCC 12版本以上CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y（GCC 12前）
CONFIG_INIT_STACK_ALL_ZERO=y#系統(tǒng)啟動時收集更多的entropy信息
CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y#強制所有結構體在傳遞給其他函數(shù)之前進行初始化
CONFIG_GCC_PLUGIN_STRUCTLEAK=y
CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y#系統(tǒng)調用推出后擦除堆棧信息，減少堆棧內舊數(shù)據(jù)的生命周期CONFIG_GCC_PLUGIN_STACKLEAK=y#隨機化系統(tǒng)結構的布局。這可能會對性能產生巨大的影響，所以請謹慎使用或使用
#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#使能系統(tǒng)調用入口上的隨機內核棧偏移量計算（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#使能伙伴系統(tǒng)分配器的內存溢出檢測功能，需要在內核5.3版本上，使能CONFIG_PAGE_POISONING=y
page_poison=1#強制IOMMU TLB失效，使設備永遠無法訪問過時的數(shù)據(jù)內容
iommu.passthrough=0 iommu.strict=1
十、結論
內核安全問題，牽一發(fā)而動全身，尤其是在配置方面，所以如果有的時候在穩(wěn)定性或者性能優(yōu)化上卡住，不妨從內核配置的角度，結合上文的詳細說明，換個角度來分析問題，可能會有更好的收獲。這篇文章著重從內核安全配置的角度來分析了KSPP，在LSM機制、漏洞利用分析、棧溢出攻擊等方面會有真實利用場景，后續(xù)會逐步更新相關文章。
下載文檔
