Bad Security: Apache suexec restrictions.

17 June, 2011 (12:04) | Bad Security, Programming

If you look at the source code for “suexec” which comes with Apache, you’ll see the following comment near the top of the program:

 ***********************************************************************
 *
 * NOTE! : DO NOT edit this code!!!  Unless you know what you are doing,
 *         editing this code might open up your system in unexpected
 *         ways to would-be crackers.  Every precaution has been taken
 *         to make this code as safe as possible; alter it at your own
 *         risk.
 *
 ***********************************************************************

I always used to joke that it’s unfortunate that the author didn’t take his own advice. I’m not saying that the whole idea of the program is bad, nor that it’s horribly insecure, but it makes the big mistake made by a lot of people when implementing security measures: assuming that one security model is always better than some other model.

The biggest mistake made by the author, in my opinion, is the fact that it enforces the fact that directories and scripts cannot be group writable. This is not a problem for extremely small websites, where there’s just one developer running a website under one account. But what about websites managed by many users? This forces the maintainers to either share an account, or use root to update the site, both of which are generally bad ideas. This completely negates the use of groups to manage permissions for websites, and thus removes options to improve security.

Another mistake is the fact that it prevents programs from being SUID or SGID. Again, the application negates a security feature of the operating system. So now we’re forced to give one account access to do everything, rather than being able to divide it up and reduce exposure.

Overall, the attitude used by the author of suexec.c is that the best way to secure a system is to turn it off. It is not difficult to make a system secure, but it is very difficult to make a system both secure and usable at the same time. I would not claim that suexec is a complete failure, just that the author turned off a lot more than he should have, and as a result forces systems to be less secure than they could be.

Write a comment