Apache2, mod_php, suexec security confusion.

June 10, 2008 6:58 AM

Apache2 security theory; mod_php versus CGI php and the use of suExec: What is the non-theoretical problem with running Apache2 with mod_php and thus without using suexec on a dedicated system?

I'm setting up a typical LAMP environment. I've used phpsecinfo to evaluate my current environment and implemented all of the recommended changes except for two, Group ID and User ID.

The distribution is the most recent Ubuntu Server with the mostly-default Apache2 configuration, and the mostly-default PHP installation, with the exception of the changes recommended by phpsecinfo.

These warnings indicate that my group and user ID numbers are below 100 (33 to be specific), and therefore may be a problem. I am not sure how to interpret this.

I followed the documentation links and was about to implement SuExec when I realized that this meant doing a lot of other reconfiguration, like not using mod_php, and that meant changing a lot of other things, etc.

This is not a shared system. It will only be used to host one company's applications through several virtual hosts. The applications will be PHP-based, and most frequently will use the Symfony framework. Apache currently runs as www-data, whose shell is /bin/false. SSH access to the system is by public-key authentication only and is further restricted at the daemon level to only specific real users.

What do I need to do to run this securely? Resources, guides and real-world examples would be greatly appreciated.

posted by odinsdream to computers & internet (7 comments total)

"What do I need to do to run this securely?"

As far as non-theoretical problems? This: "I've used phpsecinfo to evaluate my current environment and implemented all of the recommended changes except for two"

Although you could pretty easily cure the gid and uid issues by renumbering the user that runs the apache process, if you really wanted to.
posted by majick at 7:29 AM on June 10

Would simply re-numbering the user and group actually change something about the security of the system?
posted by odinsdream at 7:36 AM on June 10

No. You're being warned about low uid and gid values because customarily values under 100 may own the OS' files. There's no magical power associated with any uid other than zero, it's simply a matter of who owns what.

If it were up to me entirely, I'd just go make sure that the www-data user and group don't own any files or directories and then let 'er rip. Historically speaking, code written in PHP is going to be your biggest security vulnerability and how the httpd is configured is only a small part of that.

There's nothing wrong with hardening your server in general, but I'd be more inclined to emphasize PHP code review in your situation.
posted by majick at 8:13 AM on June 10

You are me and I claim my sanity back.

If your applications are all trusted-ish (i.e. in-house developed) you are likely already fine.

I'd strongly recommend whipping up an apparmor profile for apache and enabling it, using logprof to add to that profile when apache crashes because you forgot some obscure php lib.

If you're running untrusted-ish code (i.e. multiple authors who you can't throttle/fire) I'd recommend investigating the subprofile support in apparmor to give individual apps their own subprofiles to keep them in their own little worlds.
posted by Skorgu at 8:25 AM on June 10

This is mostly a concern of shared hosting environments; if user A and user B both have PHP that runs as the Apache user, as it does with mod_php, then both users can read the files owned by the others, since the apache user can also see it. This can be a concern since said files can often contain, e.g. authentication information for a database.

This goes doubly for the case where their scripts are writing files; they have to be writable by your apache user, and so anyone who can make it run a script can read and modify these files. This is actually rather common; Smarty, for instance, writes out PHP code compiled from templates and then include()d; hence other users can make your website execute arbitrary PHP by modifying them

PHP tries to mitigate these issues with things like open_basedir and the soon-to-be defunct safe_mode, but they can be slow and not entirely effective. You're correct that SuExec can mostly mitigate this, but also that this might be a fair amount of work, especially if you also need it to be fast (e.g. SuExec FastCGI).

Ultimately, it's down to how much trust you place in the PHP you're running, the people who can modify that PHP, and how much effort you're willing to expend to make things more secure/isolated. If you're processing credit cards, you might want to do more than if you've just got a forum and a blog.

What we did (and we're not a shared environment, just paranoid) was to put apache in a jail, with only mod_fastcgi and the other important core modules and only the files critical to make it run, and put PHP in another similarly cut down jail, running as a standalone FastCGI server, with a number of other applications not even necessarily on the same machine. This is probably extreme overkill for you depending on what you're doing, and is certainly more work than just setting open_basedir.
posted by Freaky at 8:46 AM on June 10 [2 favorites]

For a dedicated machine, serving a single simple webapp, assuming files in the filesystem are owned by their regular users, I see no additional advantage to moving to a suexec or suphp approach. There's even a disadvantage, because suphp will want to make sure that the user it runs as owns the files it interprets (which is a potential security hole because wayward scripts could modify their own contents).

However, if you're running multiple webapps, particularly webapps with different authors who may or may not know how to cooperate or to write secure code, you (and the other authors) might want to start looking into a stricter webapp hosting environment. In particular, you might want to isolate each webapp into running code under its own particular user, using suexec, suphp, or something similar.

In shared hosting environments, a common concern is that another webapp on the same host is actively malicious, and you want to protect your applications from the potentially-malicious ones. This is not your situation (it's not shared hosting, it's a single organization's server), but you're still not in the clear, because non-malicious webapps can be poorly-written, and it sounds like you've got more than one webapp.

A poorly-written webapp is often capable of allowing an end user to take some level of detailed control over what it does on the server side (through various vulnerabilities, such as raw PHP or SQL injections, misuse of global variables, etc). If your apache processes all run code as the same user, then a single compromised webapp means that all of the data accessible to any webapp on that machine could be leaked or tampered with. If you've isolated each webapp to run as a different user, a single compromised webapp can only expose the data belonging to it.

Of course, if all your webapps are just frontends to a single RDBMS, and they all use the same authentication credentials to access the RDBMS, then you might as well run apache as a single user. Restated more positively, if you're going to separate your apache users for the sake of security context isolation, make sure you separate your RDBMS authentication/authorization as well (and make sure that any config files storing RDBMS credentials are readable only by the appropriate system users).
posted by dkg at 1:08 PM on June 10

Thanks to everyone for your suggestions. I'm going to more closely review the permissions of the www-data user/group, but will not implement suexec given the usage of the machine.

The development group in our case is very small and communicates frequently. Stepping on eachothers' toes with our code isn't a major concern, especially from a data security standpoint. Nonetheless, we still give each application separate and minimal RDBMS credentials. The web server itself stores no critical data.
posted by odinsdream at 7:52 AM on June 12