[Pkg-clamav-devel] Bug#989549: clamav-daemon: any local user can shut clamd down via control socket

[Stephane Chazelas]

Some additional notes, from discussion on the Ubuntu bugs:

1. dpkg-reconfigure dialogs say in the first dialog:

   "The ClamAV suite won't work if it isn't configured".
   However, that dialog is not displayed upon install, and
   except for
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979077
   clamd does work out of the box (after a reboot for instance
   to address 979077).

2. While via dpkg-reconfigure, we can restrict access to the
   socket and somewhat mitigate the vulnerability, it's not
   really an acceptable solution, as that socket is used both
   for the service and for daemon control, so by restricting
   access to the socket, we're preventing access to the service,
   and clients that need access to the service (MTAs, ftp, web
   servers...) are not the same as the ones that are meant to
   control the daemon (systemd, freshclam...).

3. The systemd service unit uses default Type=simple with clamd
   started in foreground. That means clamd is considered up and
   active before it is ready to accept requests. Using
   Type=forking (and remove the --foreground) would address
   that. (reinstating PidFile in clamd.conf would (according to
   systemd doc) make the MainPID detection more reliable and
   help with shutting down / reloading when access to the socket
   is restricted. See also
   https://github.com/extremeshok/clamav-unofficial-sigs/issues/392)

4. I'd expect a number of packages which depend on clamd or can
   be configured to do so currently rely on clamd being
   configured with the socket publicly accessible. Those would
   have to be taken into account in any fix to the issue. At the
   Ubuntu bug, I mention e2guardian or clamsmtp which depend on
   clamav-daemon though I've not looked at those in details.

   There's also amavis which is typically used with clamd for
   email filtering.

   To mitigate the issue on a deployment  where clamd is used
   only by amavis, I changed the socket permissions to be
   rw------- clamav clamav, change the Type to forking as per
   above, and added an ACL to the socket file upon creation for
   amavis to be able to connect to it:

--- /lib/systemd/system/clamav-daemon.service	2021-06-04 15:05:34.272466670 +0100
+++ /etc/systemd/system/clamav-daemon.service	2021-06-04 15:05:36.072489235 +0100
@@ -6,11 +6,11 @@
 ConditionPathExistsGlob=/var/lib/clamav/daily.{c[vl]d,inc}
 
 [Service]
-ExecStart=/usr/sbin/clamd --foreground=true
+Type=forking
+ExecStart=/usr/sbin/clamd
 # Reload the database
 ExecReload=/bin/kill -USR2 $MAINPID
-StandardOutput=syslog
-TimeoutStartSec=420
+TimeoutStartSec=5min
 
 [Install]
 WantedBy=multi-user.target
--- /dev/null	2021-06-04 15:21:19.232000000 +0100
+++ /etc/systemd/system/clamav-daemon.service.d/amavis.conf	2021-06-04 15:19:37.335686866 +0100
@@ -0,0 +1,10 @@
+[Unit]
+Before=amavis.service
+
+[Service]
+# clamd allows its clients to shut it down! So access to /run/clamav/clamd.ctl
+# is restricted to a strict minimum. That's only members of the clamav group.
+# The amavis process can only be in one group. It also doesn't need access to
+# any of clamav's private resources. So we're only granting it access to the
+# socket.
+ExecStartPost=/usr/bin/setfacl -m u:amavis:rw /run/clamav/clamd.ctl

(requires acl package. Could be improved by adding PidFile to clamd.conf and
systemd service unit).

-- 
Stephane