Our very large organization has developed a standard for hosting of applications which dictates that the application and all components on which it relies must reside in a dedicated application volume distinct from the operating system itself. For instance, if the application is written in Perl, we require a separate instance of Perl to be maintained within the application volume.
The reasoning behind this is that those components which are relied on by both the OS and by an application can and often do have conflicting version requirements, and forcing the application to maintain its own resources makes it much easier to patch the OS. Also, it ensures that application data and logs don't get stuffed into the locations where the OS-based tools are (this is particularly critical with respect to httpd, for example).
Furthermore, unless there is a valid and documented technical reason, the application processes must run as an unprivileged user identity and not as root. We have workarounds in place in Linux so that processes such as web servers can be run as an unprivileged user and accept connections forwarded from the privileged ports (80 and 443) to the unprivileged ports they are listening to.
For perspective, I'm a security professional in the Unix/Linux SA organization at my company and I work closely with the platform technical support specialists to maintain and enforce the standards I've laid out above. A large part of my responsibilities is vetting requests for privileged access via sudo, which are centrally managed. Our standard Linux is Red Hat, but Ubuntu and CentOS are also being considered for cloud environments.
The problem is that we are currently being bombarded with requests from application teams to permit them (via sudo) to install Linux applications with rpm and yum, as vendors require this and aren't able to provide any alternative means to install the applications. This conflicts with our standards in multiple ways:
The rpm and yum tools must be run with root privileges. This means that everything they do operates as root, so the resulting installation must often be tweaked after the fact to allow it to run as an unprivileged user.
Packages often specify that the components must be installed in the root volume rather than under a specified volume. Where the root of the package tree can be specified, often vendors insist that it remain unchanged because they have only tested it in the precise environment specified in the packages.
Finally, rpm and yum pull in dependencies from any repository available to the system, and although we require applications to use our Satellite repository for anything available from Red Hat, oftentimes the vendors provide their own repos which must be included for the software to work.
My question is, how does one specify or restrict the use of rpm and yum in such an environment to ensure that package conflicts do not occur and system security patches can be safely applied, while not banning the use of these tools for application software altogether (which we have been doing until now and have discovered it is an exercise in futility)?