ComplianceAsCode项目中文件权限规则修复失败的技术分析

问题背景

在ComplianceAsCode项目的日常产品化审查过程中，发现了一个关于审计规则文件权限的重要问题。具体表现为file_permissions_etc_audit_rulesd规则在修复后仍然失败，影响了多个测试场景和不同RHEL版本的合规性检查。

受影响范围

该问题主要影响以下测试场景：

• 镜像构建过程中的STIG合规性检查
• 安装程序(Anaconda)的DISA对齐扫描
• 带GUI和不带GUI安装的STIG合规性检查
• Kickstart安装场景中的STIG合规性检查

涉及的RHEL版本包括8.10.0、9.6.0和10.0的最新更新版本。

问题现象

系统检查发现/etc/audit/rules.d/目录下的两个关键文件：

• delete.rules
• modules.rules

这些文件的实际权限为0640，而合规性规则期望的权限应为0600。这种不匹配导致规则验证失败，同时也造成了与DISA标准的不一致问题（SSG结果为失败而DISA结果为通过）。

技术分析

这个问题可能源于最近合并的一个PR（编号12737），该PR涉及审计规则文件权限的修改。从技术角度看，0640和0600权限的主要区别在于：

0640权限意味着：

• 所有者有读写权限(6)
• 组用户有读权限(4)
• 其他用户无权限(0)

而0600权限则更严格：

• 所有者有读写权限(6)
• 组用户和其他用户都无权限(0)

在安全审计场景下，审计规则文件通常包含敏感信息，需要严格控制访问权限。0600的权限设置可以确保只有文件所有者能够访问这些文件，符合最小权限原则。

解决方案建议

要解决这个问题，可以考虑以下几个方向：

1. 规则调整：重新评估审计规则文件的实际使用场景，确认是否需要调整规则要求从0600放宽到0640。

2. 修复脚本修正：检查并修正自动化修复脚本，确保它能正确地将文件权限设置为0600。

3. 文档更新：如果确定0640权限是可接受的，则需要更新相关文档和规则描述，保持与实际要求一致。

4. 测试用例验证：增加针对此权限设置的专项测试用例，确保修复后的行为符合预期。

实施注意事项

在实施修复时需要考虑以下因素：

• 不同RHEL版本间的行为一致性
• 自动化修复过程对现有系统的影响
• 与DISA等合规标准的对齐
• 向后兼容性问题

结论

文件权限设置是系统安全的基础要素之一，特别是在审计子系统这样的关键组件中。ComplianceAsCode项目需要确保其规则既能满足安全要求，又能在实际环境中可靠地实施。这个问题的解决将有助于提高项目在不同部署场景下的可靠性和一致性。