[refpolicy] php-fpm policy

[refpolicy] php-fpm policy

[Matt Thode]

It may need a little bit of work as far as what permissions it needs on apache (I think it needs rw access to apache).
Some of the optional stuff may need to be fleshed out (different connect options and the like).

Attached are the te and fc files.

-- Matthew Thode

-------------- next part --------------
A non-text attachment was scrubbed...
Name: phpfpm.fc
Type: application/octet-stream
Size: 440 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20111111/b9241d43/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phpfpm.te
Type: application/octet-stream
Size: 2327 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20111111/b9241d43/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20111111/b9241d43/attachment.bin 

[refpolicy] php-fpm policy

[Sven Vermeulen]

On Fri, Nov 11, 2011 at 11:57:44AM -0600, Matt Thode wrote:
> It may need a little bit of work as far as what permissions it needs on apache (I think it needs rw access to apache).
> Some of the optional stuff may need to be fleshed out (different connect options and the like).

Apart from the coding style itself, a few remarks that I had at the first
skim through the policy...

The use of apache_manage_sys_content() seems wrong in my opinion. PHP-FPM is
a parser which should have read access. The moment it needs to write stuff
as well, that "stuff" should be labeled appropriately (either
http_sys_rw_content_t, or create a type like httpd_squirrelmail_t did).

I also am not clear on why you have the following:
  #allow search on /usr/include/netipx (I don't know if this is really necessary)
  userdom_search_user_home_dirs(phpfpm_t)

Seems that the comment doesn't match the policy, and I think the policy is a
result of trying stuff out while you were located in someone's $HOME (in
which case, just by getting the current working directory, most applications
have "search" done although not needed).

Wkr,
	Sven Vermeulen

[refpolicy] php-fpm policy

[Sven Vermeulen]

On Tue, Nov 22, 2011 at 08:22:24PM +0100, Sven Vermeulen wrote:
> The use of apache_manage_sys_content() seems wrong in my opinion. PHP-FPM is
> a parser which should have read access. The moment it needs to write stuff
> as well, that "stuff" should be labeled appropriately (either
> http_sys_rw_content_t, or create a type like httpd_squirrelmail_t did).

Been looking at this thing a bit more closely; shouldn't we include an
interface apache_rw_sys_rw_content, which offers read/write access to the
httpd_sys_rw_content_t type? 

Using apache_manage_sys_content also provides read/write access to the
regular httpd_sys_content_t whereas we would need to use this on
httpd_sys_rw_content_t only.

Another approach would be to use attributes to differentiate between the
regular ("httpdcontent"), ra ("httpd_ra_content") and rw
("httpd_rw_content") file types in use by the various apache-related
domains, and then use those attributes to provide the necessary accesses,
like:
  apache_manage_all_content --> httpdcontent (which is already in place)
  apache_manage_ra_content  --> httpd_ra_content
  apache_manage_rw_content  --> httpd_rw_content

Any thoughts on this?

Wkr,
	Sven Vermeulen