Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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)?

share|improve this question
    
Package conflicts are addressed by RPM itself - if the RPM installs, there are no conflicts, and any future conflicts will be handled at that point. Honestly, the insisitence that application not be installed in the root volume should be waived for properly packaged RPMs, IMHO. –  John Jul 18 at 19:28
    
Never yse RPM directly, use yum only! You can grant sudo access for stuff like "yum install company-app-prefix-*" and control the priority of repositories from yum configuration, just in case there are packages with the same name that could potentially be installed. –  Florin Asavoaie Jul 18 at 19:42
    
Is this standard actually in use? It seems impossible. In theory RPMs are relocatable; in practice most are not. I bet perl isn't. Can you give an example of a non-trivial RPM you allow the app team to install that is relocated to the app volume? –  Mark Wagner Jul 18 at 21:26
    
@MarkWagner: That's why I said we used to ban the use of rpm and yum altogether. Applications were to either use tarballs or compile from source, so that they could be installed by the user ID that would run the software, not root. –  Mike McManus Jul 18 at 23:11
    
You used to ban the use of RPMs? I have never worked in a very large org but it sounds like any progress would be glacially slow. Compiling from source usually has a negative effect on security unless you have a team that is dedicated to monitoring all software compiled from source for security vulnerability announcements and that team is also given early private notification of impending major vulnerability disclosures like Red Hat et al. are. Sounds like your only "solution" is to role your own RPMs for each app with a custom --prefix and be prepared to backport any security patches ASAP. –  Mark Wagner Jul 19 at 1:12

2 Answers 2

Before we get into solutions, a few words about your company's security standards. Put simply, they're very difficult to work with, and so outdated as to be nearly irrelevant.

It's obvious why they're difficult to work with, so I won't say any more about that.

As for being outdated, it's clear that they do not take into account modern technologies such as virtualization, Linux capabilities, containers, SELinux, etc., all of which help to solve the same security problems in much more elegant and usable ways.

By way of example, binding httpd to a high port and then redirecting traffic to it with iptables, rather than simply letting it bind and then drop privileges, as it does by default, borders on paranoia and gains you virtually nothing. It also complicates using SELinux with httpd, since this sort of setup wasn't envisioned with the design of the httpd SELinux policy.

In the same way, just blindly requiring packages to stuff themselves into /opt or /usr/local gains you nothing, as RPM already maintains the separation you require regardless of where packages are installed (unless the package is broken, which may be the case with third party vendor packages, but such would refuse to install) and loses standards compliance, possibly making relevant SELinux policies unusable, and creating a maintenance nightmare. Red Hat Software Collections is designed along these lines, and while it has some usability issues, building your own packages by this design could be a stop-gap measure while you work on the real issues.

The biggest problem I see, though, is maintaining a "big iron" sort of server, or servers, on which everyone's applications run side-by-side. This alone introduces its own security issues, which is probably the origin of these "security practices." Virtualization is quite mature at this point and simply separating applications into their own VMs, e.g. with KVM on RHEL 6 or RHEL 7, will eliminate the need for the majority of these "security practices."

Along those lines, since you almost certainly have a very large number of applications, creating a private cloud with OpenStack is probably going to be your best bet in the short to medium term. These would use RHEL 7 hosts and run RHEL 7, 6 and maybe even 5 guests as you probably have a bunch of those still alive and kicking. It would also give you a platform to experiment safely with new applications and operating systems, as well as allocate resources more easily by business unit, department, etc.

If virtualization is too heavyweight for some things, then move to containers (e.g. LXC/Docker on RHEL 7). These are much lighter weight and can be stripped to virtually nothing but the application package itself, and then isolated with their own filesystem, network and uid/gid namespaces, effectively cutting them off from any other container except via whatever you happen to open in the respective firewalls. Adding SELinux to either KVM virtual machines or Linux containers provides a second layer of protection, and can be turned on with about one click.

Plus, your company is full of developers who will love you forever if you start offering them OpenStack and/or Docker.

In short, it's time to evaluate modern Linux distributions and the capabilities they provide, and reassess all of the security practices in light of those capabilities.

With respect to licensing, Red Hat now offers unlimited virtualization licenses, allowing you to run unlimited RHEL VMs/containers, and of course there's also CentOS which will drop-in replace RHEL about 99.9% of the time. So there's no excuse there.

share|improve this answer

Most generic answer for your question is 'no'. During the installtion, yum/rpm needs to write to the root privileged folder locations

Normally all the binary packages are compiled to getting used at system level.You can use mock/pseudo shells to create chroot type of environments & install softwares within their homespace.

As mentioned by Mark, rolling out own RPM's will be apt solution to current scenario.

There are few reference to have a look

http://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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.