如何禁止其他 Linux 内核模块访问某些常规文件？答案

【问题标题】：How can I prohibit other Linux Kernel modules to get access to some regular files?如何禁止其他 Linux 内核模块访问某些常规文件？
【发布时间】：2020-05-01 09:26:36
【问题描述】：

问题是禁止访问某些文件（来自我的“黑名单”的文件）。这意味着除了我（我自己的内核模块）之外没有人可以读取或修改这些文件。

我已经在 StackOverflow 上问过这个问题，但我没有得到答案。只有一种解决方案可以更改文件的权限和文件的所有者。但是，这对我的目标来说还不够，因为文件的权限以及文件的所有者很容易被其他人修改。

但我没有放弃，我一直在研究这个问题。

我用指向我自己函数的指针替换了系统调用表的一些字段。因此，我设法禁止任何 USER 模块从我的黑名单中访问文件；此外，这种方法不依赖于文件的权限或文件的所有者。然而，关键词是“用户模块”。我的意思是任何内核模块仍然可以通过调用例如filp_open() 函数轻松访问我的黑名单中的文件。我查看了 Linux 代码源，结果发现我挂钩的所有这些系统调用（open、openat、...）都是简单的包装器，仅此而已。

你能帮帮我吗？有没有办法用filp_open 做一些类似于我对系统调用所做的事情？欢迎任何其他解决方案（没有挂钩）。

【问题讨论】：

不，这绝对不可能。您需要独立的硬件。
阻止对一组文件的访问不是您的问题……这是您对未告诉我们任何问题的问题的解决方案。如果您告诉我们为什么您想这样做（即实际问题是什么），我们或许可以提供不同的解决方案。
@FelixG 说得很好，这看起来像XY problem。
好的，我会尝试更详细地解释它。有一些模块（我不对它们负责，它们是由其他程序员设计的）将它们的配置数据存储在文件中（因为 Linux 中没有注册表）。我的内核模块必须使用配置数据保护这些文件免受任何外部修改。当然，允许进行一些修改，但只能通过我的模块（ioctls 请求）；但是这已经是工作的其他部分，现在我只是寻找一种方法来禁止所有外部模块访问这些文件。
@StaTik 我看到这里存在术语问题。 1) 用户空间应用程序是不是模块，它们是用户空间应用程序。内核模块是另一回事。 2) 你为什么要担心其他预先存在的内核模块修改你的文件？他们为什么要这样做？这没有道理。 3）请参阅下面我的回答，了解为什么甚至“保护”用户空间也不是那么简单。

标签： c linux security linux-kernel

【解决方案1】：

你要求的是不可能的。 理论上，这可以通过在定制的hypervisor下运行内核或在定制的硬件上运行来实现，但是会非常复杂（如果不是不可能的话）在现实中实现。

您无法保护内核不受自身影响。在任何正常情况下（即没有专用硬件或管理程序），Linux 内核在机器上以最高权限级别运行，因此可以根据需要恢复您所做的任何更改。如果您的模块需要拒绝访问某个文件整个内核，那么您所做的事情在概念上确实有问题。此外，您似乎假设其他内核模块会以某种方式“有兴趣”弄乱您的模块：为什么会这样？

此外，即使更改权限或覆盖系统调用也不能解决任何问题：除非您正确配置 kernel lockdown（内核 >= v5.4）和/或其他一些安全措施，例如 module signing （理想情况下也是安全启动），root 用户始终能够插入模块并破坏您的“安全”措施。

如果您需要剥夺root 对这些文件的访问权限，那么正如我所说的，确实存在逻辑错误。 root 用户已经可以使用它想要的任何配置文件为所欲为，当然破坏重要的配置文件会破坏系统，但这并不是你可以避免的事情。假设 root 是邪恶的，在任何正常情况下作为威胁模型都没有多大意义。

【讨论】：

好的。但是，如果某个进程想要成为唯一拥有某个文件的写权限的进程怎么办。例如，该进程打算写入的数据非常重要，以至于该进程希望确保没有人会干扰他。在Linux中真的没有办法实现它吗？真的没有为这种情况提供同步机制吗？
@StaTik 绝对 没有办法 这样做。不仅在 Linux 中，而且可能在任何其他操作系统中。正如我所说，您无法保护内核免受自身的影响。如果你想要完成的任何事情都需要依赖类似的东西，那么它从根本上是有缺陷的并且无法工作。