0

Context: On Debian, when hardening PHP I disabled and deleted a few unused PHP modules: for example, for wddx I deleted:

  • /etc/php/7.3/*/conf.d/20-wddx.ini
  • /etc/php/7.3/mods-available/wddx.ini
  • /usr/share/php7.3-xml/xml/wddx.ini
  • /usr/lib/php/*/wddx.so

When I upgraded, the PHP modules reappeared in /usr/share/php7.3-xml/xml/wddx.ini and /usr/lib/php/*/wddx.so although dpkg correctly did not add the 'enabling' configuration in /etc (thanks for the maintainer or dpkg for checking this!):

Not replacing deleted config file /etc/php/7.3/mods-available/wddx.ini
WARNING: Module wddx ini file doesn't exist under /etc/php/7.3/mods-available

Question: Is there a way, perhaps with dpkg-divert or a local dpkg trigger, to tell dpkg not to write again some files or to delete them after they are written?

P.S.

  • multiple PHP modules are packaged in php7.3-xml, and I need one of them, so it’s not possible to remove the whole Debian package.
  • the attack surface is already highly lowered given the PHP modules are not enabled, it is a refinement to also delete the .so file, hindering a human attacker and perhaps defeating a dumb automated malware script, even with root rights – obviously it should only be a part of the global defense.
  • it is possible to manually delete these files after upgrades or use a configuration management tool (Ansible, Puppet, Docker…), the question is about an integrated way of doing it with dpkg.
Seb35
  • 250
  • 2
  • 6

1 Answers1

0

I don't know a simple way to say to APT or DPKG or other packet manager "don't write some files here" because the manager works with packages and not uncompressed files.

If modules are disabled with phpdismod then they are not charged on memory, but I agree with you it's better to avoid them from the filesystem.

Maybe the better way is to use a script or ansible job to remove unecessary files. In any case, It's not on the packet manager side who the answer exists !

Martin
  • 446
  • 11