Php – Security issues of running PHP scripts as the owner of the PHP file with suexec

apache-2.2permissionsPHPSecuritysuexec

I'm using suexec to ensure that PHP scripts (and other CGI/FastCGI apps) are run as the account holder associated with the relevant virtual host. This allows for securing each users' scripts from reading/writing by other users.

However, it occurs to me that this opens up a different security hole. Previously, the web server ran as an unprivileged user, with read-only access to user's files (unless the user changed the file permissions for some reason). Now, the web server can also write to user's files.

So while I've prevented different users taking advantage of each other's scripts, I've made it so that in the event that some application has a remote code injection vulnerability, it now has not only read access but also write access to all that user's scripts and website.

How can I deal with this?

One idea I've had is to create a second user account for each user account in the system, so that each user has their own user account, and all their scripts are run under another user account. But that seems cumbersome.

Best Answer

Running PHP under the web server's permissions isn't isn't necessarily better or worse than using SuPHP. It's just different. The first model separates the owner from the web server, while the second model separates the owner (and his PHP code) from all the other users on the machine.

Using suPHP doesn't necessarily increase your overall security, it just redirects it. Instead of trying to prevent break-ins, you're isolating the sites from eachother. The justification is that, particularly in a shared-hosting environment, the former security model just wasn't working out: users constantly blew holes in their security by setting world-write permissions on everything so that the web application would work, and then a security compromise on one account would quickly metastasize to all the others on the server.

So, instead, it's common now to use tools like suPHP in large shared-hosting environments to remove the barrier between the user and his PHP application, and instead erect a barrier between a user and his neighbors.

So, in this case, you don't provide security, you provide separation. Unfortunately, suPHP requires that files be owned by the user you intend to run as, so creating a separate FTP user would be... a mess. You'd constantly have to chown files back and forth between the suPHP user and the FTP user.

Instead, you need to pick a role: either you secure a site, or you secure a server. If you want to secure the site, then you need to separate the webserver from the content owner. That's a somewhat complex relationship to maintain correctly, so it's not recommended for shared hosting environments. If, instead, you want to protect the server from its users, then use suPHP to separate the user (and his code) from the others on the server. In this case the user is responsible for his own security. Good luck, user! Technically it is possible to have a secure PHP application--in theory, at least.

Related Topic