现在，这可能听起来很傻，但想法是这样的：
我想让用户（即使是 root 用户）在文件上写入时需要密钥。你脑海中可能首先想到的是：
“为什么不直接加密文件呢？”
我的想法是针对某些配置文件执行此操作。它们不能加密，否则系统会崩溃。此外，使用这种方法，我仍然能够读取文件并查看它们的设置方式。
我知道这听起来从根本上违背了 Linux 系统的逻辑：为什么 root 用户会阻止自己控制自己的系统？答案是：我是 root 用户，我想保护自己不受自己的伤害。但实际上：chmod -w file当然，这很容易被逆转。
从根本上来说这可能是不可能的，但我认为问问也没什么坏处。
答案1
您正在寻找完整性保护系统，而不是加密系统。
理论上...
实现此目的的一种方法是使用数字签名– 它们通常使用非对称密钥对（例如 RSA 或 ECDSA）制作。执行写入后，您使用私钥对最终文件进行签名，并且每当执行读取时，操作系统都会使用公钥来验证签名并将其与内容进行匹配。
（您可能熟悉使用 SSH 公钥 - 嗯，它们完全相同。SSH 公钥通过签署登录质询来工作，服务器可以验证该登录质询，即“读取”，但除了您之外没有人可以“写入”。）
Linux 似乎通过以下方式支持这一点IMA/EVM 子系统。
实现此目的的另一种方法是使用纯哈希，该哈希存储在甚至 root 都不允许修改的地方。例如，Linux 有dm-verity子系统，通常用于嵌入式设备 - 整个“/”文件系统是只读的，其哈希值存储在仅引导加载程序可访问的单独闪存区域中。
在实践中...
Root 只需使用
mount --bind将另一个文件覆盖在“已验证”文件之上即可绕过这些机制。例如，即使您使 /etc/sudoers 完全不可写，root 也可以在 /tmp 中创建一个新文件，并使用mount --bind /tmp/sudoers /etc/sudoers使同一文件出现在 /etc 中。由于这发生在 VFS 层，因此它完全不受任何较低层安全保护的影响。因此，如果你真的想约束根，你将需要上述一些机制和你需要安全启动和您将需要 SELinux 或其他类似的“强制访问控制”系统，以创建额外的障碍。
或者实际上只是完全删除您自己的 root 权限。
答案2
Linux 有保险丝，一个在使用空间中实现文件系统的API。
想办法存储一个或多个密钥（以不同的方式存储，或在每个文件的开头存储）。想办法让用户传达一个密钥来解锁文件以进行写入。例如，要求该密钥作为写入的第一部分（可能具有固定长度）。或者提供您需要写入密钥的附加配套文件。想办法自动再次锁定文件，例如在超时之后。
采用示例实现并根据这些想法对其进行修改。完成。