江苏龙网

  1. 首页 > 人文 > >

@云原生之容器安全实践( 五 )


安全内核
众所周知 ， Android由于其开源特性 ， 不同厂商都维护着自己的Android版本 。 因为Android内核态代码来自于Linux kernel upstrem ， 当一个漏洞产生在upstrem内核 ， 安全补丁推送到Google ， 再从Google下发到各大厂商 ， 最终到终端用户 。 由于Android生态的碎片化 ， 补丁周期非常之长 ， 使得终端用户的安全 ， 在这过程中始终处于“空窗期” 。 当我们把目光重新焦距在Linux上 ， 它也同样存在类似的问题 。
内核面临的问题
@云原生之容器安全实践
本文插图
图7 漏洞生命周期（The Vulnerability Life Cycle）
内核补丁
当一个安全漏洞被披露 ， 通常是由漏洞发现者通过Redhat、OpenSuse、Debian等社区反馈或直接提交至上游相关子系统maintainer 。 在企业内部面临多个不同内核大版本、内核定制化 ， 针对不同版本从上游代码backport相关补丁及制作相关热补丁 ， 定制内核还需对补丁进行二次开发 ， 再升级生产环境内核或Hotfix内核 。 不仅修复周期过长 ， 而且在修复过程中 ， 人员沟通也存在一定的成本 ， 也拉长了漏洞危险期 。 在危险期间 ， 我们对于漏洞基本是毫无防护能力的 。
内核版本碎片化
内核版本碎片化在任意具备一定规模的公司都是无法避免的问题 。 随着技术的日新月异 ， 不断迭代 ， 基础架构上的技术栈需要较新版本的内核功能去支持 ， 久而久之就产生内核版本的碎片化 。 碎片化问题的存在 ， 使得在安全补丁的推送方面 ， 遭遇了很大的挑战 。 本身补丁还需要做针对性的适配 ， 包括不同版本的内核 ， 并进行测试验证 ， 碎片化使得维护成本也变得十分高昂 。 最重要的是 ， 由于维护工作量大 ， 必然拉长了测试补丁的时间线 。 也就是说 ， 暴露在攻击者面前的危险期变得更长 ， 被攻击的可能性也大大增加 。
内核版本定制化
同样 ， 因不同公司的基础架构不同、需求不同 ， 导致的定制化内核问题 。 对于定制化内核 ， 无法简单的通过从上游内核合并补丁 ， 还需对补丁做一些本地化来适配定制化内核 。 这又拉长了危险期 。
解决之道
我们使用安全特性去针对某一类漏洞或是针对某一类利用方式做防御与检测 。 比如SLAB_FREELIST_HARDENED ， 针对Double Free类型漏洞做实时检测 ， 且防御overwrite freelist链表 ， 性能损耗仅0.07%（参考upstrem内核源码 ， commit id: 2482ddec） 。
当完成所有全部的安全特性 ， 漏洞在被反馈之前和漏洞补丁被及时推送至生产环境前 ， 都无需关心漏洞的细节 ， 就能防御 。 当然 ， 安全补丁该打还是得打 ， 这里我们主要解决在安全补丁最终落在生产环境过程中 ， “空窗期”对于漏洞与利用毫无防御能力的问题 ， 同时也可以对0day有一定的检测及防御能力 。
实施策略

  1. 已经合并进Linux主线版本的安全特性 ， 如果公司的内核支持该特性 ， 选择开启配置 ， 对开启前后内核做性能测试 ， 分析安全特性原理、行业数据 ， 给出Real World攻击案例（自己写exploit去证明） ， 将报告结论反馈给内核团队 。 内核团队再做评估 ， 结合安全团队与内核团队双方意见 ， 最终评估落地 。
  2. 已经合并进Linux主线版本但未被合并进Redhat的安全特性 ， 可选择从Linux内核主线版本中移植 ， 这点上代码质量上得到了保障 ， 同时社区也做了性能测试 ， 将其合并到公司的内核再做复测 。
  3. 未被合并进Linux内核主线版本 ， 从Grsecurity/PaX中做移植 ， 在Grsecurity/PaX的诸多安全特性中 ， 评估选择 ， 选取代码改动少的 ， 收益高的安全特性优先移植 。 比如改动较少的内核代码又能有效解决某一类的漏洞 ， 再打个比方 ， Dirty Cow的全量修复可能需要花费1-2年的时间 ， 如果加了某个安全特性 ， 即使未修复也能防御 。


    推荐阅读


上一篇：[顾子明明公]涂10分钟，颈椎、腰椎、关节痛都缓解了！

下一篇：『内存』曝内存和硬盘准备涨价10%以上！还没升级的抓紧