Solution 1:

Try this

policy_module(httpd_php_fpm, 1.0)
require {
    type httpd_t;
    type var_run_t;
}

#============= httpd_t ==============

allow httpd_t var_run_t:sock_file write_sock_file_perms;
allow httpd_t var_run_t:unix_stream_socket client_stream_socket_perms;

## not sure what this is for but..
init_stream_connect_script(httpd_t)

EDIT

Thinking about it, php-fpm is practically doing what the webserver does. Try setting /usr/sbin/php-fpm and /etc/rc.d/init.d/php-fpm to httpd_exec_t and httpd_initrc_exec_t respectively, then see how that holds out.

If you rewrite a policy for it you need to consider a number of things:

  • You should probably make sure tmp files get labeled something special.
  • Make php-fpm also label var_run sockets and pid files something special, then alter apache to be able to connect to them.
  • php-fpm will probably want database access when executing PHP scripts.
  • You'll likely need to allow php-fpm to listen on specific network ports, and let apache connect back to them as well as unix sockets.
  • You need to define an fc file for specifying file contexts.
  • Make sure php-fpm can do other things like imap, pop3, smtp, http, https to name at least a few.
  • Must be able to write back into httpd content where write is permitted, and using the correct label.
  • Must be able to read into user_content types of httpd as well as system ones.

Confining what is in effect a programming language can be pretty tricky because of how robust the policy needs to be to work with many different web applications.