I don't mean to question the well established security precaution of putting apache in a chroot-jail in most scenarios but in my scenario I have doubts.
We have a virtual server hosting a single application - a webservice. This guide says I should disable SELinux which seems less secure to me? All to protect a run of the mill Centos installation after our application is compromised.
Obviously this is a bit subjective but in a small scale deployment with limited resources are there better approaches we should focus on?
Chroot provides a small bit of security to provide a speed-bump for an attacker. If you have a vulnerability in apache/CGIs, an attacker has to escape the chroot jail. Automated attacks are less likely to try to do this, but if there is a known kernel exploit and the requirements for that exploit are obtainable in the chrooted environment, you are hosed.
SELinux provides are larger bit of security, but the implementation pain is not to be sneezed at. For simple cases there might be pre-canned SELinux policies for you, but if you are doing weird/custom stuff you will need to extend them yourself. This is not terribly difficult if you have the selinux development RPMs loaded. Start out in non-enforcing mode, exercise your system completely, and then run:
That will help you develop your custom policies.
A similar step to SELinux is GRSecurity. It is less standard but is probably a little more secure the SELinux and possibly a little easier to use, though with less random people on the internet being able to help you.
Another approach is to run the web server in a VM. This gives you a bit more security but attacks have been known to be able to escape a VM environment. These would most likely be very determined attackers, though, not your normal script kiddy.
I'll just throw out there that I've never bothered to setup apache in a chroot environment. If you are thinking chroot may not be necessary, it probably isn't.