一、概述
现在Android智能设备的安全和隐私保护技术&体验已越来越好,但好多老用户,可能对早年Android手机的各类漏洞、“一键root”工具还有印象。那坐落Android系统底层的Linux内核,在那些年发展中,它的安全特点有什么变化呢?
本文是Linux内核安全技术系列的第一篇,希望通过回顾开源内核安全技术变迁过程,回答上述问题。
1.1说明
本文主要剖析开源社区中Linux内核安全加固技术、入侵检查和防御技术,常见漏洞类型及减轻技术等。不涉及Linux内核传统安全特点&机制的剖析,如LSM、MAC(SELinux)、IMA等;也不涉及某个或个别内核漏洞的详尽剖析。
1.2缩略语和术语
本文使用的缩略语和术语说明如下:
二、内核主线
通过梳理2009~2022相关公开资料,我们将LinuxKernelSecurity开源发展分成三个阶段,如右图所示:
第一阶段,200x~2014年,主要特点是“Out-of-Tree”,一方面内核社区对待安全的主流心态是“Reactive”和“securitybugsarejustbugs”,相对被动悲观;另一方面,内核主线社区外,早已有系统全面的内核加固方案(Grsecurity/PaX)。
第二阶段,2015年,内核社区集中讨论安全加固必要性,最终以芝加哥邮报批判报导(参考文末链接2015.11netofsecurity:thekerneloftheargument)为标志,社区心态转变并启动KSPP(KernelSelfProtectionProject)内核自保护项目。
第三阶段,2016~2022年,主要特点是“KSPP”,大量内核安全特点通过KSPP项目相继合入主线,并广泛应用在Android设备上。同时,内核安全涌现新的研究热点(CompilerSecurity、RUST)。
2.1、Out-of-Tree
这个阶段,Linus本人及内核社区对待安全的主流心态相对悲观和被动(reactive)的,一方面觉得安全加固对性能、稳定性有负面影响,一方面觉得安全漏洞按常规bug处理,发觉并快速修补即可。比较典型如2010年10月KernelSummit上关于security的讨论,摘录如下:
相反,此阶段也有不少开发者建议采用更积极主动(proactive)的心态应对内核安全和漏洞。比如当时还在Canonical负责UbuntuKernelHardening的KeesCook提出“Securityismorethanbugfixing”linux命令大全,建议采用主动防御机制提早发觉问题,或封堵漏洞借助路径。
但是,此阶段已涌现多个非主线社区安全项目,如RedHatExecShield、UbuntuAppArmor(2010年10月部份合入主线2.6.36)等,其中业界公认最全面系统的Linux内核安全方案则是Grsecurity/PaX项目。Grsecurity/PaX项目MaintainerBradleySpengler更是在2010年8月的LinuxSecuritySummit上发表了《LinuxSecurityin10Years》演讲,论述内核安全性不足及加固必要性。
Grsecurity/PaX
Grsecurity/PaX由两个独立社区(分别组建于2001和2000)合并而至,是一组针对LinuxKernel的安全加固补丁,以一个大patch的源码方式发布。
融合后的Grsecurity/PaX提供全面的内核安全防御机制,包括RBAC访问控制、内存corruption防御、基于编译器(GCCPlugin)特点的安全加固、文件系统加固等。Grsecurity/PaX是Linux内核安全开源领域的重要源头,其研究和特点除了影响Linux内核及其发行版,也影响到Windows、OpenBSD等操作系统。
2017年4月26日,Grsecurity/PaX宣布不再公开patch源码,仅向付费顾客提供服务。围绕此事,社区和开发者有诸多讨论,非本文重点,感兴趣读者可参考文末链接2017.05Grsecuritygoesprivate文章及评论。
(说明:Grsecurity/PaX大部份精典特点,随着KSPP项目推动,已被借鉴、移植到内核主线,在此不详尽介绍)
2.2、TurningPoint
随着Android智能手机普及,采用LinuxKernel的Android系统初期遭受安全困惑(如各类一键root工具)。一方面Android通过修补bug、使能安全特点(SELinux)提高系统安全性;另一方面,内核社区也盛行新一轮关于安全加固必要性的讨论。
2015年8月LinuxSecuritySummit大会上,LinuxfoundationAdministratorKonstantinRyabitsev发表《SecuringyourITInfrastructurebySecuringyourTeam》演讲,通过类比车辆领域安全理念和技术发展过程,指出Linux提高安全机制必要性。
LinuxSecuritySummit会后,Linux内核安全子系统MaintainerJamesMorris在电邮中呼吁2015年10月KernelSummit大会中降低“KernelHardening”主题topic,不少开发者响应并在电邮列表中进行了积极讨论。
2015年10月KernelSummit上KeesCook&JamesMorris做了《ImprovingKernelSecurity》演讲,指出securityismorethanbugfixing,并主张进行内核自保护建设。Kees梳理了常见漏洞bug及exploitation功击类型、以及对应防御技术。Linus一直很关注性能,建议杜绝对性能影响过大的安全特点。
KeesCook谈到了内核安全加固面临的挑战,例如内核社区对待安全的传统观念、方案复杂性、专家资源等。这个议程造成了开发者广泛讨论,并显然有了一些共识:为了提高用户安全性,一些牺牲是必要的(somesacrificesmayneedtobemadetoprovidethelevelofsecuritythatourusersneed)。
从2015年11月4日的文章securitypart2看,在10月上述议程后,社区核心Maintainer对提高内核安全的一些细节也进行了充分技术讨论,尽管没有明晰推论,但社区对安全的接受程度虽然有了显著转变。
从上述信息看,社区内部对安全心态早已有了转变。但巧合的是,2015年11月5日芝加哥邮报刊登了文章《netofsecurity:thekerneloftheargument》,对Linus及内核社区忽略安全的心态进行了“批判”,文章加速了社区转变进程。该报导原文较长,读者可参考文末链接,右图是11月6日的“精简版”:
芝加哥邮报导发出后,引起社区广泛讨论。几个小时后KeesCook发布了KSPP项目启动电邮。
11月6日,社区对报导风波进行了相对即将回应/总结:AnewMindcraftmoment。从内容看社区linux,社区心态相对积极,一方面才能客观的正视电邮中提及的问题(如前期社区对安全的悲观心态)。
另一方面,也进行了说明/反驳(如开发者背后商业公司的目标、投入支持等)。
最后社区觉得在转变安全观念(报导加速了这一过程)后,KSPP项目一定就能取得较好的结果(doamazingthings)。
2.3、KSPP
KSPP启动后,几乎每年(2016~2019、2021)的LinuxSecuritySummit大会上,KeesCook就会进行第一次statusupdate,说明KSPP加固项目缘由、目标、最新进展。
2020年LinuxSecuritySummit会上,Grsecurity/PaX项目MaintainerBradleySpengler又一次发表了《10YearsofLinuxSecurity》演讲,系统回顾了2011~2020年间Linux内核安全加固的重要风波、特性。
通过整理上述资料及相关信息,我们将KSPP项目整体情况归纳如下:
漏洞窗口期
KSPP在阐述加固必要性时,多次引用过内核漏洞信息。一方面,尽管开发者在发觉并修补bug,但外部attacker更擅长挖掘漏洞并借助,且通常不公开其成果,因而有潜在漏洞/借助路径存在;另一方面,内核漏洞的修补时间比多数开发者想像的要长,从引入到修补平均5.5年,因而attacker有较长利用窗口期。下边是具体数据:
1)2010年10月JonathanCorbet在其文章《Kernelvulnerabilities:oldornew?》中研究了2010年内核CVE的“生命周期”,即从commit递交引入bug到最后修补,平均持续5年。
2)2015年开始KeesCook跟踪剖析了Ubuntu内核CVE数据,从2015~2021统计数据显示,“Critical”和“High”类CVE漏洞(138个)平均修补时间为5.5年(2021.09KSPPstatus)。如右图中,横座标为CVEID,纵座标为对应内核版本号(时间),柱图表示CVE在内核中的版本(时间)跨径。
KSPP目标
KSPP目标从低到高可描述为:killingbugs->killingbugclasses->killingexploitation。
在参考安全业界对漏洞及功击分类基础上,KSPP将bugclasses、exploitation进行了界定,并规划制订了对应减轻技术方案(2016KSPPstatus)。本文整理如下:
KSPP方案
KSPP规划的Mitigations方案,从防御疗效上可分成两类:
第一类是probabilisticprotection,机率性防御或漏洞减缓,降低功击者借助漏洞的难度,典型的如KASLR(KernelAddressSpaceLayoutRandomization)内核地址随机化。
第二类是deterministicprotection,确定性防御,即修补/封堵功击者可能借助的缺陷和路径,如显存保护方案中的W^X(堆、栈显存不可执行,未能在堆栈显存上布署恶意代码)、XoM(eXecuteOnlyMemory)代码段显存只可执行不可读(依赖硬件)等。
除LinuxSecuritySummit上的例行讲演外,KeesCook在个人博客上也会总结每位kernel版本合入的新安全特点,可参考文末链接SecuritythingsinLinuxv4.x/v5.x。
结合上述信息,本文梳理了2015.11以后kernel各版本安全加固特点(已精简),汇总说明如下:
缩小功击面,解决设计实现缺陷。诸如W^Xdetection、VMAP_STACK、THREAD_INFO_IN_TASK、readonlyafterinit等。THREAD_INFO_IN_TASK是一个典型缩小功击面特点,将原先置于栈显存上的thread_info结构体,移到taskstruct全局变量中,避免功击者通过stackoverflow对thread_info结构体敏感数据(addr_limit)进行篡改。漏洞借助防御和减轻。诸如为减轻堆喷射(heapspray)功击,堆显存freelist降低随机化处理,即SLAB/SLUBfreelistASLR;诸如为避免stackbufferoverflow被借助为ROP功击,引入stackprotector;以及内核地址随机化KASLR等。信息防泄露,在敏感场景对特定显存清零。诸如STRUCTLEAK、STACKLEAK、zero-poisonafterfree、newkernelstacksclearonfork等。编译器安全技术。比如GCCPlugininfrastructure(STRUCTLEAK、STACKLEAK基于此特点)硬件安全特点使能。比如ARM64硬件安全特点TBI、PAC、BTI、MTE等;编译器安全技术。诸如基于Clang的控制流完整性技术,包括防ROP功击的shadowcallstack、防JOP功击的CFI等。
KSPP总结
KSPP历经多年开发迭代,许多特点也多次优化构建,特点基线已相对成熟稳定,初期目标基本达成,具体表现:
相比初期按bugclasses和exploitation进行分类(特点分散),新的分类简单聚合,具体可参考Linuxkernel官方文档。本文在该文档基础上,对特点和内核配置进行了简单梳理,供参考:
回顾KSPP初期目标(killingbugs->killingbugclasses->killingexploitation),及各版本安全特点合入情况对比,可看出主要bug类型、exploitation功击路径基本都有了对应减轻/加固方案,近几年安全特点的合入数目频度均增加(KeesCook博客更新频度、LSS大会上KSPPstatusupdate频度)。
2018~2022阶段,内核安全领域研究的重心和热点,已除了是内核代码的修补升级、软件加固方案,而是:新硬件安全特点使能(ARM64)、编译器安全特点(GCC&Clang)、安全编程语言(MakingCLessDangerous、RUST)。
相比多年前开源社区对待安全的心态,如今内核安全得到了软硬件厂商、各领域开发者越来越多的关注和积极参与。比如一个好的现象是:一些安全特点(尤其硬件安全特点),非安全领域的开发者或Maintainer不经过KSPP就直接完成了。
三、AndroidKernel
在近些年内核安全领域发展中,Android(Google)饰演了重要的角色。右图是LSS、LPC大会上相关安全topic的一个梳理。
第一阶段,采用Linux内核的Android设备遭受安全困惑,但是内核安全漏洞占比不少(见右图)。一方面Android通过使能安全特点(SELinux)、修复bug、缩小功击面等手段提高系统安全性;另一方面积极推进和投入KSPP项目(KeesCookJoinGooglein2011),引入更多安全加固特点。详情可参考文末资料2016Android:Protectingthekernel和2018YearinReview:AndroidKernelSecurity。
第二阶段,针对Android系统和内核碎片化、升级慢问题,先后引入Treble和GKI项目进行构架前馈,便捷设备厂商快速升级内核,降低使用低版本(漏洞)内核的设备数目和曝露时间,同时引入高版本内核安全提高。
第三阶段,探求新技术提高Android和Kernel安全性。诸如推进Clangbuildkernel,使内核态和用户态编译工具链归一,以便在GKI内核中默认开启Clang安全特点(如CFI),提高整体安全性;另外,2019年业界RUSTforkernelmodule有了阶段进展后,Android(Google)也在推动探求使用RUST语言开发内核驱动(2021AndroiddriversinRUST),由于driver漏洞在内核漏洞中占大多数。
GCC和Clang编译器安全特点对比见右图,详情可参考文末链接:2021CompilerFeaturesforKernelSecurity。
四、开源社区
除主线社区KSPP内核自保护项目外,开源社区也有许多其他内核安全方案。其中一类是HIDPS(Host-basedIntrusionDetection&PreventionSystem)主机入侵检查&防御系统。这类方案聚焦怎么实时、动态的检测入侵/功击行为,并拦截或及时上报。典型开源方案有OpenWall社区的LKRG(LinuxKernelRuntimeGuard)、HITACHI的AKO(AnotherKernelObserver)等。
限于篇幅,本文只做简单介绍,待后续文章中再做详尽剖析。
LKRG是OpenWall社区2018年发布的内核入侵检查防御技术,以内核KO方式加载(故可适应多种Linux发行版和内核)。
其主要原理是通过监控内核代码段、只读数据段、敏感变量/数据(如selinux_enabled/selinux_enforcing)、任务权限数据(如cred、uid/euid)等的完整性,来判定是否有入侵行为并及时拦截。
2020.03EffectivenessofLinuxRootkitDetectionTools论文评测显示,LRKG对于内核Rootkit的防御有较好的疗效。
AKO是HITACHI研究者在2017年LinuxSecuritySummit上公开的内核入侵检查防御技术(参考文末链接2017ProposalofamethodtopreventprivilegeescalationattacksforLinuxkernel)。
其主要原理是监控系统调用前后caller进程的credential权限数据,排除合法加壳(setuid/setgid等)后,判定是否发生了非法加壳/功击。
原理和性能影响如右图,测试疗效和2020年论文(Additionalkernelobserver:privilegeescalationattackpreventionmechanismfocusingonsystemcallprivilegechanges)显示对这种系统调用加壳功击有较好的测量疗效。
五、总结&展望
本文回顾2010~2022年开源内核安全技术的发展和变迁过程,包括初期内核社区对待安全的心态及转变、KSPP项目的背景方案及进展,Android(Google)在内核安全领域的技术和贡献、及其他开源社区HIDS方案等。希望能帮助读者对Linux内核安全技术的发展有一个整体的认识。
受限于篇幅,好多技术细节和专题(如ARM64硬件安全特点、编译器安全特点、CFI技术方案对比、HIDS方案细节等)未能深入剖析,这种内容计划在后续《Linux内核安全技术》系列文章中再展开分享。
六、参考资料(上下滑动可查看)
2010.08LinuxSecurityin10Years,
2010.11Securityismorethanbugfixing
2012.06PaX,20yearsofPaX
2012.10PaX,12yearsofsecuringLinux
2012.10PaX,kernelselfprotection
2013.10PaX,GCCplugin
2015.08JamesMorris社区linux,Ksummit-discuss,KernelHardening
2015.10PaX,RAP:RIPROP
2015.10ImprovingKernelSecurity
2015.11netofsecurity:thekerneloftheargument
2016.08KSPPstatus
2016.08Android:Protectingthekernel
2017.04grsecuritylinux系统镜像下载,PassingtheBaton
2017.09KSPPstatus
2017.09ProposalofamethodtopreventprivilegeescalationattacksforLinuxkernel
2018.08KSPPstatus
2018.08YearinReview:AndroidKernelSecurity
2018.08MakingCLessDangerous
2019.08KSPPstatus
2019.08WritingLinuxKernelModulesinSafeRust
2020.06Additionalkernelobserver:privilegeescalationattackpreventionmechanismfocusingonsystemcallprivilegechanges
2020.0710YearsofLinuxSecurity
2021.09KSPPstatus
2021.09CompilerFeaturesforKernelSecurity
UbuntuKernelHardening#Upstream%20Hardening
GRSecurity:
PaX:
LRKG:
SecuritythingsinLinuxv4.x/v5.x
Linux内核黑科技|技术文章|精选教程