|
微软推出了 Integrity Policy Enforcement(IPE) 项目，该项目主要是为解决 Linux 的代码完整性问题，这是微软致力于 Linux 内核上的新项目，下面我们来了解一下。
详细介绍 Integrity Policy Enforcement（IPE），是 Linux 安全模块（Linux Security Module，LSM），它允许可配置的策略在整个系统上强制执行完整性要求。 Linux 内核中已有多种实现，可以解决某种程度的完整性验证。例如，device-mapper verity（确保块设备的完整性）和 fs-verity（确保文件系统的完整性的系统）。这些实现缺少的是一种运行时验证的措施，该验证来自这些位置，IPE 旨在解决这一差距。 IPE 是微软为解决 Linux 的代码完整性问题而进行的尝试。分为两个主要部分：由 LSM 提供的可配置策略（“IPE Core”），以及由内核提供的用于评估文件的确定性属性（“IPE Properties”）。目前，IPE 尚处于 RFC（request for comments）状态。 在启用了 IPE 的 Linux 系统上，系统管理员可以创建允许执行的二进制文件列表，然后添加内核在运行每个二进制文件之前需要检查的验证属性。如果攻击者更改了二进制文件，IPE 还可以阻止恶意代码的执行。 微软方面表示，IPE 设计用于具有特定目的的设备，例如嵌入式系统（e.g. 数据中心中的网络防火墙设备），其中所有软件和配置均由管理员构建和提供。理想情况下，利用 IPE 的系统不适用于通用计算，也不使用第三方构建的任何软件或配置。 IPE 支持两种操作模式：permissive 模式（类似于 SELinux 的 permissive 模式）和 enforce 模式。其中，enforce 模式是默认模式。Permissive 模式执行与 enforce 模式相同的检查，并记录 policy violations 情况，但其不会强制执行策略，这使得用户可以在 enforce 策略之前对其进行测试。 此外，微软称，与 Linux 内核中已有的用于代码完整性的 LSM（例如 IMA）不同的是，IPE 不依赖于文件系统元数据，并且因为 IPE 属性是仅存在于内核中的确定性属性，所以它不需要像 IMA 一样需要 IMA 签名的其他代码。
已知问题 IPE 无法验证匿名可执行存储器的完整性，例如 gcc 闭包和 libffi 或 JIT 代码创建的问题。由于这是动态生成的代码，因此 IPE 无法从该代码的构建位置到运行位置检测到该代码没有被篡改。结果，IPE 无法为动态生成的代码解决此问题。 通过 <interpreter> <file> 调用这些脚本时，IPE 无法验证解释语言程序的完整性。这是因为解释器执行这些文件的方式不会通过 IPE 的其中一个钩子将脚本本身评估为可执行代码。在打开文件并适当响应错误代码之后，尝试将文件映射到可执行内存（+X），可以使口译员对 IPE 的使用有所了解。这也适用于包含的文件或高价值文件，例如关键系统组件的配置文件。计划在 IPE 内部解决这一具体差距。
项目链接 Integrity Policy Enforcement (IPE) 项目地址
相关主题 |
