smarter, safer, faster, more secure php for WordPress whm/cpanel webhosting

I’ve written about this before, but I have new ideas, but I’ll start with a short recap.

WordPress needs to be able write to the FileSystem for things like updates, new plugins, caching.

But , for a large proportion of web requests, WordPress really only needs read-only access to the filesystem. (more detail here).

What the hackers rely on is some hole, in code, a plugin, server config, anything. And 99% of the time they scribble something onto the filesystem – and then they execute that. Even cases where the hack starts off in the database, part of the hack is generally scribbling something to the filesystem.

In general the webserver and php has access to write anything they like to the filesystem whenever they are asked. It’s only WordPress core/plugin/theme logic preventing hackers.

If you breakdown, and generalize the problem a bit:

• php needs mostly readonly access to filesystem
• php sometimes needs write access also
• I think the webserver only ever needs readonly access (but I’m not 100% sure on that one – do uploaded images go through php?)
• generally the write is always enabled, and this is what hackers use
• if we could turn off writes most of the time we’d close the door to most hacks/hackers

This is where ‘php handlers’ come into play on whm/cpanel. There seems to be a lot of options: apache DSO, apache suPHP, apache CGI, apache DSO/mpm_itk, php-fpm. And more if you consider non standard like nginx and litespeed.

It seems suPHP is ‘out-of-the-box’ standard for whm/cpanel. It does a reasonable job, it runs each request as the user that owns account that the request is for. It is super slow as it fires up a new php process each time, and op code caching is empty each time. Opcode caching is pretty important for php 5.6 and 7.0.

Some that persist the php process lack security, or don’t offer php write access at all, or make a nightmare of managing filesystem permissions. But, they do go super fast.

They ALL lack the ability for mostly readonly, and only some requests get write access. So they are all vulnerable to hacks.

DSO with mpm_itk comes closest in my opinion. Code is executed as the file owner(generally the account owner), and php processes are persisted so opcode caching works properly. mpm_itk seems to be a dropin replacement for suPHP – and it’s much faster – so if you do nothing else consider mpm_itk. What is still missing is readonly for most requests, and only elevate to write permissions for select tasks – like /wp-admin/ requests.

Here is my idea for a solution:

• apache with DSO and mpm_itk
• if (iPprivileged)   use the default mpm_itk logic/user for the rest of requests
• else    use ‘AssignUserIDExpr nobody’ for most requests
• (isPrivileged) would be something like  url ~ /wp-admin/ , or cookies ~ wp_loggedin, or has authenticated (so you put an apache passwd over  /wp-admin/)
• there are some corner cases with ajax calls, and emoji

The theory is, most requests end up with apache and php is a ‘nobody’ readonly jail. Nobody would have readonly on all files in public_html/ – which whm/cpanel defaults too. And if you are privileged you escape the jail, but only get user access.

So the pinnacle of all this is when a hack hits your site, get’s ‘nobody jailed’, attempts to write to disk, the linux kernel stops it dead.

So as each request comes in , we work out yes or no, safe or unsafe, write or readonly.

The solution is likely to be half a dozen lines added to a virtualhost – not sure if I could get it more global than that.

I haven’t tried/coded the above yet, looking for ideas, comments. Do you understand all/most of this ? Is it important to you ? Would you use it ? How else can/have you handled all this ?

ps. I do have this working now, in beta testing

By Scott Farrell on April 19th, 2016 , Follow @scott_WordPress Tweet to @scott_WordPress