Table of Contents
ClamAV, permessi e Apparmor
Con Debian 10 Buster il demone clamd viene installato con il pacchetto clamav-daemon. La configurazione predefinita nel file /etc/clamav/clamd.conf prevede:
LocalSocket /var/run/clamav/clamd.ctl LocalSocketGroup clamav LocalSocketMode 666 User clamav ...
Cioè il demone viene eseguito a nome dell'utente non privilegiato clamav, la comunicazione tra il client (ad esempio clamdscan) e il demone clamd avviene tramite il socket /var/run/clamav/clamd.ctl che ha mode 0666 e appartiene a clamav.clamav.
Esecuzione a nome di root
Una configurazione sconsigliata (e fondamentalmente inutile) potrebbe essere quella di eseguire il demone a nome dell'utente root; in passato questo era necessario per poter accedere ad ogni file del filesystem, ad esempio per oter controllare gli allegati di posta elettronica appartenenti ali utenti del sistema.
Questa configurazione (oltre che sconsigliata) non è di immediata realizzazione. Modificando la configurazione /etc/clamav/clamd.conf in questo modo:
User root
non ottiene il risultato desiderato. Dopo aver eseguito systemctl restart clamav-daemon.service si verifica che il servizio fallisce e syslog riporta:
kernel: audit: type=1400 audit(1592300396.191:22): apparmor="DENIED" operation="capable"
profile="/usr/sbin/clamd" pid=9619 comm="clamd" capability=0 capname="chown"
clamd[9619]: Tue Jun 16 11:39:56 2020 -> !Failed to change socket ownership to group clamav
In pratica esiste una regola di apparmor che impedisce al programma eseguire il chown del scoket, nonostante i permessi di root (anzi, proprio per quello!).
ATTENZIONE: Avviare il servizio richiede più di un minuto su sitemi non troppo performanti.
ATTENZIONE: Il socket /var/run/clamav/clamd.ctl viene comunque creato appartenente a root e questo potrebbe compromettere l'avvio del demone in altre condizioni.
Il problema è causato dal fatto che Debian installa il pacchetto apparmor e il pacchetto clamav-daemon installa il profilo /etc/apparmor.d/usr.sbin.clamd. Con il comando aa-status si verifica che quel profilo è in enforce mode:
aa-status apparmor module is loaded. 18 profiles are loaded. 17 profiles are in enforce mode. ... /usr/sbin/clamd ...
Se si desidera mantenre l'infrastruttura apparmor attiva, è comunque possibile disabilitare il profilo clamd. È necessario installare il pacchetto apparmor-utils ed eseguire quanto segue (viene creato un link simbolico in /etc/apparmor.d/disable/):
aa-disable /etc/apparmor.d/usr.sbin.clamd
Il socket verrà creato con i seguenti permessi:
srw-rw-rw- 1 root clamav 0 Jun 16 12:08 /var/run/clamav/clamd.ctl
Per verificare che clamd stia girando con i permessi di root, è sufficiente richiamare clamdscan su un file che non sia world-readable:
chmod 600 /root/mail-test-eicar-antivirus.com clamdscan /root/mail-test-eicar-antivirus.com /root/mail-test-eicar-antivirus.com: Eicar-Signature FOUND
Il profilo clamd resta disabilitato anche dopo un reboot, viene eventualmente ripristinato in caso di rimozione e reinstallazione del pacchetto clamav-daemon oppure utilizzando il comando aa-enforce.
Esecuzione senza privilegi di root
Ovviamente la soluzione ottimale è lasciare che clamd venga eseguito senza privilegi di root. In queste condizioni un file non-world readable non è direttamente accessibile da clamd:
clamdscan /root/mail-test-eicar-antivirus.com /root/mail-test-eicar-antivirus.com: lstat() failed: Permission denied. ERROR
La soluzione è utilizzare il parametro --fdpass di clamdscan che consente (solo lavorando su Unix socket) di passare il file descriptor al demone:
clamdscan --fdpass /root/mail-test-eicar-antivirus.com /root/mail-test-eicar-antivirus.com: Eicar-Signature FOUND