本帖最后由 神代すみれ 于 2024-11-3 07:41 编辑
kernel_lockdown - 内核镜像访问防护功能
描述
Kernel Lockdown 功能旨在防止直接和间接访问正在运行的内核镜像，试图保护内核镜像免受未经授权的修改，并防止访问内核内存中的安全和加密数据，同时仍允许加载驱动模块。 如果访问或使用了受限制或禁止的功能，内核将发出如下消息： Lockdown：X：Y 受限制，请参阅 man kernel_lockdown.7
其中 X 表示进程名称，Y 表示受限制的内容。 在启用 EFI 的 x86 或 arm64 机器上，如果系统以 EFI 安全启动模式启动，则会自动启用锁定。 覆盖范围当锁定生效时，许多功能将被禁用或限制使用。这包括允许直接访问内核镜像的特殊设备文件和内核服务： /dev
/mem
/dev/kmem
/dev/kcore
/dev/ioports
BPF
kprobes
以及直接配置和控制设备的能力，以防止使用设备访问或修改内核镜像： • 使用模块参数直接指定硬件参数给驱动程序，通过内核命令行或加载模块。
• 使用直接 PCI BAR 访问。
• 在 x86 上使用 ioperm 和 iopl 指令。
• 使用 KD * IO 控制台 ioctls。
• 使用 TIOCSSERIAL 串行 ioctl。
• 修改 x86 上的 MSR 寄存器。
• 替换 PCMCIA CIS。
• 覆盖 ACPI 表。
• 使用 ACPI 错误注入。
• 指定 ACPI RDSP 地址。
• 使用 ACPI 自定义方法。
某些操作受到限制：
• 只有有效签名的模块可以加载（如果模块文件被 IMA 评估，则豁免）。
• 只有有效签名的二进制文件可以 kexec（如果二进制映像文件被 IMA 评估，则豁免）。
• 不允许未加密的休眠/挂起到交换，因为内核镜像保存到可以访问的介质中。
• 不允许使用 debugfs，因为这允许一系列操作，包括直接配置、访问和驱动硬件。
• IMA 需要在安全启动锁定模式下将“secure_boot”规则添加到策略中，无论它们是否在命令行上指定，用于内置和自定义策略。
版本
Kernel Lockdown 功能是在 Linux 5.4 中添加的。 注意
Kernel Lockdown 功能由 CONFIG_SECURITY_LOCKDOWN_LSM 启用。lsm=lsm1,...,lsmN 命令行参数控制 Linux 安全模块的初始化顺序。它必须包含字符串 lockdown 才能启用 Kernel Lockdown 功能。如果未指定命令行参数，则初始化将回退到 security= 命令行参数的值，然后回退到 CONFIG_LSM 的值。
版权信息 https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.html
额外部分（另一篇文章） https://mjg59.dreamwidth.org/55105.html
Linux 内核锁定补丁（Linux kernel lockdown patches）已于去年合并到 5.4 内核中，这意味着它们现在是多个发行版的一部分。对于我来说，这是一段 7 年的旅程，这意味着很容易忘记其他人对代码的投入不如我一样。以下是这些补丁的目的、为什么以当前形式实现以及在部署该功能时需要考虑的问题。 Root 是一个用户——一个特权用户，但仍然是一个用户。Root 不同于内核。以 root 身份运行的进程仍然无法解引用属于内核的地址，仍然受制于调度器的随机性等。但是，历史上这个边界一直很脆弱。各种接口使得 root 可以直接修改内核代码（例如加载模块或使用 /dev/mem），而其他接口则使得 root 不那么直接（例如能够加载新的 ACPI 表，这些表可能会导致 ACPI 解释器覆盖内核）。在过去，这并不是一个重大的问题，因为当时没有广泛部署的机制来验证内核的完整性。但是，一旦 UEFI 安全启动广泛部署，这就成了一个问题。如果您验证了引导链，但允许 root 修改内核，则验证引导链的好处就会大大减少。即使 root 不能修改磁盘上的内核，root 也可以热补丁内核，然后通过在系统启动时放置一个二进制文件来使其持久化。 锁定（Lockdown）旨在通过提供一个可选的策略来避免这种情况，该策略关闭了允许 root 修改内核的接口。这是最初实现的唯一目的，它对应于当前实现中的“完整性”模式。以锁定完整性模式启动的内核可以防止甚至 root 使用这些接口，从而增加了对运行内核与引导内核相对应的保证。但是，锁定的功能已经被扩展。有一些用例，即使防止 root 修改内核也不够——内核可能持有秘密信息，即使 root也不应该被允许看到（例如，EVM 签名密钥可用于防止离线文件修改），而完整性模式并不防止这种情况。这就是锁定的保密模式的用途。保密模式是完整性模式的超集，具有对 root 使用可能允许检查包含秘密的任何内核内存的功能施加额外限制。 不幸的是，目前我们没有强大的机制来标记哪些内核内存包含秘密，因此为了实现这一点，我们最终阻止了对所有内核内存的访问。毫不奇怪，这损害了人们出于完全合法的原因检查内核的能力，例如使用允许跟踪和探测内核的各种机制。 我们如何解决这个问题？有几种方法： 1：引入一种机制来标记包含秘密的内存，并仅限制对这些内存的访问。我曾试图为用户空间做类似的事情，结果发现很难，但这可能是最好的长期解决方案。
2：添加对具有适当签名的特权应用程序的支持，实现用户空间侧的策略。这实际上已经可能了，尽管不是那么直接。锁定是在 LSM 层实现的，这意味着可以使用任何其他现有的 LSM 来施加策略。例如，我们可以使用 SELinux 来施加保密限制于大多数进程，但允许具有特定 SELinux 上下文的进程使用它们，然后使用 EVM 来确保任何在该上下文中运行的进程都具有合法的签名。这对于通用发行版来说是一个很大的障碍。
3：在通用发行版中不使用保密模式。它所保护的攻击主要是针对特殊用途的用例，它们可以自己启用保密模式。
我的建议是选择（3），我鼓励启用锁定的通用发行版仅在完整性模式下启用，而不是保密模式。保密模式的成本与其提供的好处相比太高了。需要保密模式的人可能已经知道他们需要，并且应该能够自己启用它并处理后果。 翻译时听的歌曲： https://music.163.com/#/song?id=1440345204
塞ぐ目に落ちる景色の様に
就像坠落在捂住双眼上的景色
霞む私は誰のものでも無いの
缥缈的我不属于任何人
buy me
so feeling
からかわないで
不要捉弄我
私だけに見せて
只让我来看
歪な夜をどうぞ
这扭曲的夜晚
| 
发表于 2024-11-3 07:36:38
楼主