When explaining the implications of privileges given to the user that Apache (httpd) is set to handle web requests as (typically the system user apache, www, or nobody) web designers and even developers usually begin zoning out. These wonderful souls are in the business of making scripts work and content to be served quickly with a minimum of fuss. Moreover, these persons are motivated to make maintaining the sites under their control as easy as possible, more often than not by using a web application as a Content Manangement System. Thus, it is often expeditious for a person in this role (content provider, application developer) to give more privileges to the Apache user (defined in httpd.conf; hereafter referred to as "apache") and not less. When a "permissions denied" or "file not found" error can be corrected with a quick relaxation of permissions, this person opts to let 'er rip. If "chmod 777 filename.html" is good, "chmod -R 777 *" is even better! No, it's not.

To drive home the importance of limiting the privileges given to apache, I have started using a new alias for this user: "The Russian Hacker:"

The user that httpd runs as (typically, apache, uid 48) is an alias for visitors accessing your server through the httpd process. I like to call this the "Russian Hacker user" to emphasize the fact that anyone with access to web content (via the HTTP/HTTPS protocols) on your server accesses your system with the privileges of this user. Since web servers are generally open to anyone on the Internet, I chose the "most unlikely visitor" you'd give access to your server to as the "user." Whatever you would give a Russian Hacker permission to do on this server, allow the httpd user to do. Conversely, whatever you would NOT want a Russian Hacker to be able to do on your server, accordingly deny the httpd user that privilege. Giving apache write privileges or ownership privileges needs to be made with full awareness of this security risk.

This technique has proven quite successful at defeating the "glazed response" and has illicited urgent requests for security audits, guidelines, suggestions for best practices, etc., from those person in roles generally more concerned with functionality than security. Something about visualizing a Russian Hacker on the other side of Apache rather than one's self or one's frustrated client helps get us admins and develpers/designers on the same page.

I welcome your feedback on this technique. Corrections, too.

Shortly after writing the above post someone pointed me to an article/forum posting maintaining that I am full of baloney and explaining Why chmod 777 is NOT a security risk. To which I respond: FAIL.

I really cannot believe such a post is allowed to exist. But, then, I guess it does explain Joomla, Mamba, and a host of CMS scripts that live as if chown -R apache:apache $DOCUMENT_ROOT; chmod -R 0777 $DOCUMENT_ROOT is a proper use of the command line.