On most web servers, PHP normally executes as the user "nobody" and is ran as an Apache module. The ability to execute arbitrary code as an unprivileged user may lead to modified web content, denial of service, or further compromise. With that said, why does an unsafe configuration still reign as default for many web hosts? Perhaps it has just been the
quick and dirty way to get a server up and running. This setup also leaves something to be desired in file and permission structure.
Since there was never an official Web Hosting Manual, the quick way has been the only way far too long. The bad guys have now had more than enough time to romp around the stateless protocol. They are all knowing of the fact that thousands upon thousands of servers are humming along in this disorganized state, fully welcoming of their trespasses. But running hundreds of nameless processes seems silly, doesn't it? Why would a person responsible for a piece of the Internet even think allowing anonymous activity made sense? And if we usually want things the fast and easy way, how can we expect something this tangled to be managed properly? It's especially peculiar when you consider the learning curve faced by reseller account holders turned server managers.
Even though I have painted a dark scene, this setup is
not such a bad thing on a server which houses only a few accounts. On the other hand, a web hosting company with thousands of customers dotted across a server farm will absolutely need a different approach for keeping track of user activity.
PHP can really exist in pseudo server harmony even though it is the most major source of problems for many hosts. Just one change is a great start to regaining control of your network. Just take a look at how PHP is running on your server: PHP running as "nobody" is not the way to go. Since web-based PHP applications spell doom, all processes need to be attached to the usernames of your customers. An easy way to fix that is to run PHPsuexec. Once you do this you can also completely disallow emailing from old-style scripts which send messages via nobody (such as dated contact forms and guestbooks).
"PHPsuexec is the shortened term often used to describe running PHP as a CGI [module] with suexec. Running PHP as a CGI with suexec creates a much more secure environment compared to running PHP as an Apache module." A quick Google search revealed this fairly thorough article on phpsuexec
which you can find here. If you have any qualms or critiques on how nobody can become somebody, please let me know!
More About Kayla
Surpass Hosting
mod_php offers a significant performance advantage over running PHP as a CGI, and this increase in performance is critical for a webhost, especially on a machine with hundreds or thousands of virtual domains.
mod_php runs as the same unprivileged user that Apache runs as, typically "nobody". In this configuration Apache remains unprivileged and for the most part, reliably secure. Running something like PHPsuexec would not only introduce an additional setuid binary, but could also potentially open up a very serious security hole if there were a vulnerability found in PHPsuexec.
Alot of webhosts are migrating to PHP/FastCGI which offers somewhat similar performance to mod_php, and allows user privileges to be set via the same suexec mechanism as normal CGIs.
Another key component to keep on the watch list is the very experimental, but upcoming "perchild" MPM (http://httpd.apache.org/docs/2.0/mod/perchild.html...) which is a hybrid forking+threading model MPM which has the ability to set per virtualhost user/group privileges.
From your comments it is clear to see that we have quite a few options here. I wish there was a straight answer.. but it does seem that we are still experimenting a bit.
FastCGI uses a similar approach, but this time the interpreter runs outside of Apache. Requests come in, and apache dispatches requests to the FastCGI PM process which handles the request on the PHP (or perl/ruby) interpreter already resident in memory.
As for hard evidence, there are many benchmarks floating around on the subject. Here's an example.
http://chamas.com/bench/graph.asp?type=hello
Howeever, I suggest you do your own benchmarks to see the real difference it makes.
I am mainly concerned that some hosts are afraid of a performance issue and will not implement a solution at all. A few years ago most all spam reports we received originated from the user nobody. But now we completely disallow that and instead deal with what I'd call "real" spam which stems from other issues. I would not like to work in the abuse division for a company that has not yet experimented with different configurations. It would not be very organized or efficient.
http://hostingfu.com/article/running-php-on-shared...
phpsuexec is great for tracking script execution (especially php spamming) but it doesn't work with code that was designed insecurely. In fact, many hosts don't enable safe_mode with php. They install software which contains a ton of world readable and writable directories, and they don't update to the latest security patches.
A simple search for world writables on a server running something like phpBB ( find / \( -perm -a+w \) ! -type l >> world_writable.txt ) will yield alarming results.
Most hosts don't see the bigger picture. Prices and quick setup help gain customers but without security and stability, you can't retain them. By putting in place proper security measures when using PHP, you can create a relatively secure server. By choosing the defaults, you're opening yourself up to a lot of overtime and headaches.
Absolutely well said.
Very true.
More true: TRY TO FIND A MANUAL ON PHPSUEXEC! Is there one? Where?? Is it readable???
This is why Linux has never made it big time. Everyone, and I mean Everyone writes code, contributes, but no one documents. And those who ad 'notes' and 'discussions' aren't fluent in English.
"And the wheels on the bus go round 'n round, round 'n round......."
Performance is not poor, its not great either. The security is definitely worth the speed trade-off!