我们非常大的组织已经开发了一个托管应用程序的标准，该标准规定应用程序及其所依赖的所有组件必须驻留在与操作系统本身不同的专用应用程序卷中。例如，如果应用程序是用 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 从系统可用的任何存储库中提取依赖项，尽管我们要求应用程序使用我们的 Satellite 存储库来获取 Red Hat 提供的任何东西，但供应商通常会提供他们自己的存储库，软件必须包含这些存储库才能运行。
我的问题是，如何在这样的环境中指定或限制使用 rpm 和 yum 以确保不会发生包冲突并可以安全地应用系统安全补丁，同时又不完全禁止将这些工具用于应用程序软件（直到现在我们一直在做并且发现这是徒劳的练习）？
在我们讨论解决方案之前，先谈谈贵公司的安全标准。简而言之，它们很难使用，而且已经过时以至于几乎无关紧要。
很明显为什么它们很难使用，所以我不会再多说。
至于过时，很明显它们没有考虑到虚拟化、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。所以那里没有任何借口。
您的问题最通用的答案是“不”。在安装过程中，yum/rpm 需要写入根特权文件夹位置
通常所有的二进制包都被编译以在系统级别使用。您可以使用模拟/伪 shell 来创建 chroot 类型的环境并在其主空间中安装软件。
正如 Mark 所提到的，推出自己的 RPM 将是适合当前情况的解决方案。
有几个参考看看
https://unix.stackexchange.com/questions/134181/building-rtmpdump-on-rhel-x86-without-yum-and-no-root-rights http://www.linuxquestions.org/questions/linux-software -2/can-i-run-yum-without-root-privileges-592939/ http://yum.baseurl.org/wiki/RunningWithoutRoot