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:
audit2allow -a -l -R -m foo -o foo.te
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.
