使文件在 Linux 上只读，即使对于 root 用户也是如此

Question 1

将其刻录到 CD 或 DVD 上。一次性可写的类型，而不是可擦除的类型。或者某种其他类型的只读设备。

好吧，我想您想要一个软件解决方案，所以这里有一些想法：您可以创建一个 SELinux 规则集来禁用所使用的系统调用^(*)chattr，即使对于 root 也是如此。另一种可能性是使用能力：设置+i需要CAP_LINUX_IMMUTABLE能力，因此如果您可以安排所有进程的能力边界集不包含该能力，那么没有人可以更改这些标志。但您需要支持才能init将其应用于所有流程。系统可以做到这一点，但我认为需要针对每项服务单独完成。

^{(* 也许是一个ioctl替代品。)}

但是，如果您这样做，请记住，通常的 root 可以从原始设备修改文件系统（这就是用途debugfs），因此您也需要防止这种情况，并防止修改内核（加载模块）。可以使用kernel.modules_disabledsysctl 阻止加载模块，但我不确定是否阻止访问原始设备。并使所有相关配置文件也不可变。

无论如何，在那之后，您还需要防止更改系统启动方式，否则有人可以使用允许覆盖上述限制的内核重新启动系统。

Answer

将其刻录到 CD 或 DVD 上。一次性可写的类型，而不是可擦除的类型。或者某种其他类型的只读设备。

好吧，我想您想要一个软件解决方案，所以这里有一些想法：您可以创建一个 SELinux 规则集来禁用所使用的系统调用^(*)chattr，即使对于 root 也是如此。另一种可能性是使用能力：设置+i需要CAP_LINUX_IMMUTABLE能力，因此如果您可以安排所有进程的能力边界集不包含该能力，那么没有人可以更改这些标志。但您需要支持才能init将其应用于所有流程。系统可以做到这一点，但我认为需要针对每项服务单独完成。

^{(* 也许是一个ioctl替代品。)}

但是，如果您这样做，请记住，通常的 root 可以从原始设备修改文件系统（这就是用途debugfs），因此您也需要防止这种情况，并防止修改内核（加载模块）。可以使用kernel.modules_disabledsysctl 阻止加载模块，但我不确定是否阻止访问原始设备。并使所有相关配置文件也不可变。

无论如何，在那之后，您还需要防止更改系统启动方式，否则有人可以使用允许覆盖上述限制的内核重新启动系统。

Question 2

你想要的是强制访问控制。它允许您指定一组权限，内核不允许覆盖这些权限，即使是 root 也不允许覆盖这些权限。 SELinux 是一个著名的此类系统，斯马克另一个例子是 AppArmor 是第三个这样的系统。在 Linux 中，它们的实现为Linux 安全模块，一种通用工具，用于控制传统类 UNIX 安全模型之外的访问。除了现有的通用系统之外，您当然可以创建自己的用于特殊目的的系统。

当然，root 能够打开或关闭整个设施或更改文件的 MAC 权限，其中一些系统甚至允许将这些功能授予非 root 用户。但是，根据系统的不同，也可以禁用此功能。我知道 SELinux 和 Smack 使这成为可能；我怀疑所有 LSM 都这样做。一旦禁用，恢复该功能的唯一方法是重新启动内核。然后，您将希望引导过程在启用用户访问之前禁用该功能。如果您的内核和启动过程是安全的，则只能通过物理删除存储介质来更改此类配置（至少在理论上）。

例如，如果您使用 SMACK，您可以执行以下操作：

chsmack -a _ <file>

这会将文件设置为具有特殊标签“_”，该标签仅允许读取或执行访问，但不允许写入。现在，即使是 root 也无法写入此文件（一旦 SMACK 已被激活并且安全覆盖功能已被禁用，如上所述）。

但是，您还必须确保您的内核是安全的。默认情况下，root很容易颠覆内核，因为内核信任root用户。如果 root 只能删除安全模块，那并没有多大帮助。此类方法的列表是这里，但请注意，这样的列表不可能真正适合所有情况。

最后，根据您的情况，您可能需要保护启动过程。对于拥有唯一物理访问权限的计算机，可能不需要这样做，但为了获得最大的安全性，您确实需要加密的文件系统和安全的内核启动方式，例如 UEFI 安全启动。

Answer

你想要的是强制访问控制。它允许您指定一组权限，内核不允许覆盖这些权限，即使是 root 也不允许覆盖这些权限。 SELinux 是一个著名的此类系统，斯马克另一个例子是 AppArmor 是第三个这样的系统。在 Linux 中，它们的实现为Linux 安全模块，一种通用工具，用于控制传统类 UNIX 安全模型之外的访问。除了现有的通用系统之外，您当然可以创建自己的用于特殊目的的系统。

当然，root 能够打开或关闭整个设施或更改文件的 MAC 权限，其中一些系统甚至允许将这些功能授予非 root 用户。但是，根据系统的不同，也可以禁用此功能。我知道 SELinux 和 Smack 使这成为可能；我怀疑所有 LSM 都这样做。一旦禁用，恢复该功能的唯一方法是重新启动内核。然后，您将希望引导过程在启用用户访问之前禁用该功能。如果您的内核和启动过程是安全的，则只能通过物理删除存储介质来更改此类配置（至少在理论上）。

例如，如果您使用 SMACK，您可以执行以下操作：

chsmack -a _ <file>

这会将文件设置为具有特殊标签“_”，该标签仅允许读取或执行访问，但不允许写入。现在，即使是 root 也无法写入此文件（一旦 SMACK 已被激活并且安全覆盖功能已被禁用，如上所述）。

但是，您还必须确保您的内核是安全的。默认情况下，root很容易颠覆内核，因为内核信任root用户。如果 root 只能删除安全模块，那并没有多大帮助。此类方法的列表是这里，但请注意，这样的列表不可能真正适合所有情况。

最后，根据您的情况，您可能需要保护启动过程。对于拥有唯一物理访问权限的计算机，可能不需要这样做，但为了获得最大的安全性，您确实需要加密的文件系统和安全的内核启动方式，例如 UEFI 安全启动。

Question 3

没有办法做到这一点。有人总是能够将文件恢复为可写状态，除非该文件位于 CD-ROM 等只读介质上。您可以root使用 SELinux 权限有效地阻止这样做（我不知道如何做到这一点，或者我会提供一个示例），但是拥有权限的用户仍然可以撤消某些操作。

Answer

没有办法做到这一点。有人总是能够将文件恢复为可写状态，除非该文件位于 CD-ROM 等只读介质上。您可以root使用 SELinux 权限有效地阻止这样做（我不知道如何做到这一点，或者我会提供一个示例），但是拥有权限的用户仍然可以撤消某些操作。

Question 4

“有没有一种方法可以使系统上的每个人都可以读取文件，但任何人（甚至是 root）都不能写入文件，并且无法返回”

对此有几点想法：

(1)如果您使用可写 CD 或 DVD，则它对每个人来说都是只读的。没有回头路了。

(2)某些外部介质具有 WriteProtect 开关和 WriteProtect 标志，即使 root 用户也无法禁用；它需要人为移除WriteProtect开关，并且WriteProtect标志不能被重置。
如果您可以将 WriteProtect Switch 与卡硬件一起使用，则可以控制写入；即使root也无法控制它。
如果设置了 WriteProtect 标志，则无法返回。
（感谢@fluffysheap 使这个更加准确）

(3)如果该文件位于本地计算机的文件系统上，那么最初编写该文件的人可以撤消更改，然后更改该文件。因此不可能满足您的条件。

(4)对于本地文件，最接近的是使用虚拟磁盘或 ISO 映像文件；当它被安装时，它将不允许写入。但是 root 可以创建一个包含新内容的新 ISO，并将该新 ISO 写入原始 ISO。

(5)如果该文件位于其他服务器上，那么这里有一个解决方案。在远程计算机上配置 Web（HTTP 或 HTTPS）服务器或 FTP 服务器或 NAS 服务器。应允许所有本地用户（包括 root）通过挂载（远程服务器应仅提供只读访问）或通过 HTTP 或 FTP（例如）来访问它；本地用户将无法写入该服务器或禁用此限制。即使本地 root 也不能在那里写入。您需要远程服务器上的 root 访问权限才能更改文件。

Answer