Hi, I think that the php-fpm systemd service should be hardened. php's security
is particularly important, as it is a widely used, long-running service with a
lot of responsibilities and privileges.

Upstream has been shipping an hardened systemd service for a few years[1][2],
and I really think that Debian should do the same, if not better.

I've been running php with a really strict set of hardenings for a while, but
some of them are really tailored to my specific setup and can't be applied by
default. I'm leaving an attached patch with some hardenings that I believe are
safe to deploy for everyone. My setup is fairly limited though, and further
testing is required.

With the supplied configuration, `systemd-analyze security php7.4-fpm` reports
an overall exposure level of 2.3, and that's extremely good if compared to the
9.6 score of the current unit :D

Thanks for your work on the php packages!

1: https://bugs.php.net/72510

2: https://github.com/php/php-
src/commit/40c4d7f1820df1872a71ab07fd26da45a203e37f


- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages php-fpm depends on:
pn  php8.1-fpm  <none>

php-fpm recommends no packages.

php-fpm suggests no packages.
-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYmE+zBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuScv0AQCi+nRjV57XdEX4adIrWGrcNDFGukWT
sTsO/DEN1RFiLwEA2XMbOKPnr1bcdFFy1n01ePk4TjK2DO5mt6TpVpBDjA0=
=3j1J
-----END PGP SIGNATURE-----

Attaching an updated patch, since the one I attached in the first
message has `PrivateNetwork=true` in it, an that obviously breaks PHP

Hello,

I'm using this patch on two different servers, and have not encountered
any issues.

I'm running with chroot'ed pools, and relatively complex/common
applications like Drupal, Wordpress and Nextcloud.

Thanks,

So it seems I wasn't doing my tests correctly and the patch does indeed
need adjustment to work with chroot'ed pools:

Add the CAP_SYS_CHROOT capability and "chroot" to the system call filter.