大型安装环境下使用rpm和yum进行应用安装

Question

我们非常庞大的组织已经开发了一个应用程序托管标准，该标准规定应用程序及其依赖的所有组件必须驻留在与操作系统本身不同的专用应用程序卷中。例如，如果应用程序是用 Perl 编写的，我们需要在应用程序卷中维护一个单独的 Perl 实例。

这背后的原因是那些被操作系统和应用程序所依赖的组件可能并且经常有冲突的版本要求，并且强制应用程序维护自己的资源可以更容易地修补操作系统。此外，它还确保应用程序数据和日志不会被塞入基于操作系统的工具所在的位置（例如，这对于 httpd 尤其重要）。

此外，除非存在有效且记录在案的技术原因，否则应用程序进程必须以非特权用户身份而不是 root 身份运行。我们在 Linux 中制定了解决方法，以便诸如 Web 服务器之类的进程可以作为非特权用户运行，并接受从特权端口（80 和 443）转发到它们正在侦听的非特权端口的连接。

从角度来看，我是我公司 Unix/Linux SA 组织的一名安全专家，我与平台技术支持专家密切合作，以维护和执行我在上面列出的标准。我的很大一部分职责是通过集中管理的 sudo 审查特权访问请求。我们的标准 Linux 是 Red Hat，但 Ubuntu 和 CentOS 也在考虑用于云环境。

问题是我们目前正受到来自应用程序团队的要求允许他们（通过 sudo）使用 rpm 和 yum 安装 Linux 应用程序的请求，因为供应商需要这样做并且无法提供任何替代方法来安装应用程序。这在多个方面与我们的标准相冲突：

• rpm 和 yum 工具必须以 root 权限运行。这意味着他们所做的一切都以 root 身份运行，因此最终的安装必须经常在事后进行调整，以允许它以非特权用户身份运行。

• 包通常指定组件必须安装在根卷中，而不是在指定的卷下。在可以指定包树的根的地方，供应商通常坚持它保持不变，因为他们只在包中指定的精确环境中对其进行了测试。

• 最后，rpm 和 yum 从系统可用的任何存储库中获取依赖项，尽管我们要求应用程序使用我们的卫星存储库来获取 Red Hat 提供的任何内容，但供应商通常会提供他们自己的存储库，这些存储库必须包含在内，软件才能正常工作。

我的问题是，如何在这样的环境中指定或限制使用rpm和yum，以确保不会发生包冲突并可以安全地应用系统安全补丁，同时不完全禁止将这些工具用于应用软件（直到现在我们一直在做并且发现它是徒劳的）？

Answer 1

在我们进入解决方案之前，先简单介绍一下贵公司的安全标准。简而言之，它们很难使用，而且已经过时以至于几乎无关紧要。

很明显为什么他们很难合作，所以我不会再多说。

至于过时，很明显他们没有考虑到现代技术，如虚拟化、Linux 功能、容器、SELinux 等，所有这些都有助于以更优雅和可用的方式解决相同的安全问题。

举例来说，将 httpd 绑定到一个高端口，然后使用 iptables 将流量重定向到它，而不是简单地让它绑定然后放弃特权，就像默认情况下那样，接近于偏执，并且几乎没有任何好处。它也使使用带有 httpd 的 SELinux 变得复杂，因为这种设置不是在 httpd SELinux 策略的设计中设想的。

同样，只是盲目地要求软件包将自己塞进去/opt或/usr/local一无所获，因为无论软件包安装在哪里，RPM 都已经保持了您所需的分离（除非软件包损坏，第三方供应商的软件包可能就是这种情况，但这样会拒绝安装）并失去标准合规性，可能会使相关的 SELinux 策略无法使用，并造成维护噩梦。Red Hat Software Collections就是按照这些思路设计的，虽然它存在一些可用性问题，但通过这种设计构建您自己的软件包可能是您处理实际问题时的权宜之计。

不过，我看到的最大问题是维护一个“大铁”服务器或多个服务器，每个人的应用程序都在这些服务器上并行运行。仅此就引入了其自身的安全问题，这可能是这些“安全实践”的起源。虚拟化在这一点上非常成熟，只需将应用程序分离到它们自己的 VM 中，例如在 RHEL 6 或 RHEL 7 上使用KVM，将消除对大多数这些“安全实践”的需要。

沿着这些思路，由于您几乎可以肯定拥有大量应用程序，因此在中短期内，使用 OpenStack 创建私有云可能是您的最佳选择。这些将使用 RHEL 7 主机并运行 RHEL 7、6 甚至 5 个来宾，因为您可能有一堆还活着的人。它还将为您提供一个平台来安全地试验新应用程序和操作系统，以及更轻松地按业务部门、部门等分配资源。

如果虚拟化对于某些事情来说太重了，那么就转向容器（例如RHEL 7 上的 LXC/Docker）。它们的重量要轻得多，几乎可以剥离到应用程序包本身之外，然后与它们自己的文件系统、网络和 uid/gid 命名空间隔离，有效地将它们与任何其他容器隔离开来，除非通过您碰巧在各自的防火墙。将 SELinux 添加到 KVM 虚拟机或 Linux 容器可提供第二层保护，只需单击一下即可打开。

另外，如果你开始向他们提供 OpenStack 和/或 Docker，你的公司里到处都是会永远爱你的开发人员。

简而言之，是时候评估现代 Linux 发行版及其提供的功能，并根据这些功能重新评估所有安全实践。

在许可方面，Red Hat 现在提供无限制的虚拟化许可，允许您运行无限制的 RHEL 虚拟机/容器，当然还有 CentOS，它会在 99.9% 的情况下直接替代 RHEL。所以没有任何借口。