-   Linux - Server (
-   -   Apache Virtual Hosting security with SuExec: file and directory permissions (

krasl 08-03-2010 05:18 PM

Apache Virtual Hosting security with SuExec: file and directory permissions
Hello, I have a question pertaining to Apache virtual hosts.

I am currently running a 4-year-old server (Fedora Core 4) hosting about 80 websites configured as Apache 2 virtual hosts and running PHP. (this server also runs BIND, Sendmail, and a CGI webmail program). I have a brand new server that I want to migrate these sites to. I am trying to learn the best way to secure this server. Currently I'm using PHP safe_mode (which is deprecated in the newest versions of PHP), but not much else, and I'm not happy with this setup.

I have read a ton of documentation about SuExec and suPHP, and as I can tell, they are very similar in their function.

To test various options, I have implemented a CentOS 5 install on my new server, with Virtualmin and its default modules installed using the Virtualmin installer script. It automatically installed and configured Apache with SuExec enabled for the /home directory. I have tested and this works great: users' PHP scripts are run with their user credentials instead of the 'apache' user. So far, this is as it should be.

However, I'm seeking to add more security because I don't like the idea of my hosting users being able to read /etc/passwd or list all the mail files in /var/spool/mail. Also, I have no idea what files in /etc (or any other directories) could possibly contain passwords or other sensitive information, so I'd rather err on the side of caution by blocking access to any unnecessary directories and files.

In my tests, I created a PHP file on one virtual host which simply takes an input and 'exec's it. I could exec such things as 'cat /etc/passwd' and 'ls /var/spool/mail' and see the entire output because these files/directories have world readable permissions. However I could not execute such commands as 'cat /etc/shadow' since that file is not world-readable.

My real question is this: what files/directories can I remove world-readable permissions from without breaking the O/S? Apache apparently requires world-readable permission on /etc because it stopped serving pages when I removed this permission :).

I just don't feel comfortable with users being able to see *everyone's* username and get a list of everyone's email addresses by looking in /var/spool/mail. I'm sure there are other files which users shouldn't see as well. I'm just not sure where they are.

So the real question is:
If you wanted to secure such a server, which directories and files could be set as non-world-readable without compromising system stability?

Or is there a better way?

Thank you very much for any information!


troop 08-03-2010 06:47 PM


Or is there a better way?
use chroot

krasl 08-04-2010 08:41 AM


Originally Posted by troop (Post 4054729)
use chroot

Yes, I did research this option, but it seems to cause a lot of configuration snags (sendmail, DNS lookups, etc don't work due to the chroot jail, and have to be reconfigured in an unusual way).

I am wanting to run some sort of control panel for my users which can automatically create the domains and modify settings for them w/o the need for them to edit config files. I currently use Virtualmin/Webmin and it works quite well (not to mention free). Not sure how this would handle chrooted Apache install.

So what about directory security? Does it even matter if users can see /etc/passwd? Are there other common files which could potentially expose sensitive information and which can have their permissions tightened?

Additionally, what problems can you see with giving users shell access? (we currently do NOT allow shell access) What could they potentially do with limited accounts?

Maybe this question should have been posted in the Security section because I'm really trying to determine how to best lock down my directory structure regardless of the means by which users access the system. So if this is done right, users should be able to access the system via SSH, FTP, etc. without being able to damage anything or view confidential information. Am I missing something here?


All times are GMT -5. The time now is 04:37 PM.