在 OpenStack 中使用 Rootwrap

大多数 rootwrap 过滤器过于宽松，允许以 root 用户身份运行命令，而无需对给定的参数进行额外的过滤，并且对输入的命令几乎不进行清理。

此外，维护命令过滤器也很困难。我们发现，在应该删除它们之后，未使用的过滤器仍然存在。

最后，rootwrap 无法轻松表达特权命令用例的精确语义。

特权化还是不特权化，这是个问题

在尝试使用最佳实践完成特权任务之前，应该分析该任务，以查看是否可以以非特权方式完成该任务。例如，使用文件权限和所有权进行访问的服务帐户，而不是以 root 用户身份运行命令。

此外，文件可以由项目组而不是 root 组拥有。在架构更改是首选方案的情况下，这些情况是首选解决方案，而使用特权访问可能会引入安全问题。

做好必要的事情

Rootwrap 目前存在一些缺陷

  • rootwrap 过滤器的审计

  • 创建新的过滤器类以反映命令的语义

  • 将现有的 CommandFilters 替换为 RegExpFilters

  • 可靠地审计由此产生的复杂的正则表达式

相反，更好的方法是多方面的

  • 在正在执行的任务与正在运行的命令之间创建一个抽象

  • 利用 Linux 操作系统中当前可用的特权分离机制

  • 尽可能避免调用外部命令

  • 允许对特权任务的输入进行清理

  • 提高围绕审计特权任务实现使用的易用性

  • 允许每个项目拥有特定于领域的任务

  • 与其他项目共享通用任务

  • 在创建更好的特权分离的同时，尽可能减少开发人员的负担

这些指南将允许更好地对每个任务传递的参数进行语义过滤。例如，如果我们需要在特定的文件系统子树中挂载镜像或设备，调用者不需要传递挂载点的完整路径。此外，每个外部命令或库都会对其参数进行自己的解释，我们需要能够以任务特定和用途特定的方式清理这些参数。

对过滤和清理代码进行审计也是必要的，并且需要使其更容易进行，以便可以根据需要进行。

展望未来

在 OpenStack 项目中，需要了解如何更好地限制通用命令的使用。例如，DeleteLink 不应该能够删除任意路径。讨论正趋向于一个特权守护进程，类似于最近为 neutron 提出的一个。这将提供几个优势，包括更好的 SELinux 和 AppArmor 配置文件，因为必要的权限将明确地在代码中声明。这还有助于系统调用，包括直接调用和外部调用。不幸的是，这似乎与上述构建更好方法的最后一个要点相矛盾。但是，为了保护 OpenStack 项目，这是必要的。

另一种选择是接受项目（例如 nova-compute）需要以 root 用户身份运行，因此需要对其进行全面审计 - 包括 rootwrap 过滤器。SELinux 和 AppArmor 配置文件的责任在于部署者创建和维护。

下一步

所有对 rootwrap 的调用，或项目特定的 rootwrap 接口，都应迁移到项目特定的特权任务模块中的接口。这将仍然调用 rootwrap，但将允许进行更好的清理，识别可以合并到共享代码中的内容，并允许更轻松地迁移到未来的解决方案。

应审计当前代码库，以确定是否有任何特定位置可以重新架构以避免以 root 用户身份运行任务。一个查找 rootwrap 使用情况的 Bandit 插件将允许轻松识别需要审计的代码。

提供有关如何为 rootwrap 编写安全过滤器的更好文档将使开发人员能够接受更好的教育，并且还将为审查者提供一个可引用的文档，以便在 Gerrit 中链接。

应支持 neutron 特权分离守护进程，以建立经验并了解这种实现的最佳实践。

确定最终解决方案后，应定期对其进行审计，以确保正确使用它并且结果如预期。

参考