====== 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:

<file>
LocalSocket /var/run/clamav/clamd.ctl
LocalSocketGroup clamav
LocalSocketMode 666
User clamav
...
</file>

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:

<file>
User root
</file>

non ottiene il risultato desiderato. Dopo aver eseguito **systemctl restart clamav-daemon.service** si verifica che il servizio fallisce e syslog riporta:

<code>
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
</code>

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**:

<code>
aa-status 
apparmor module is loaded.
18 profiles are loaded.
17 profiles are in enforce mode.
   ...
   /usr/sbin/clamd
   ...
</code>

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/**):

<code>
aa-disable /etc/apparmor.d/usr.sbin.clamd
</code>

Il **socket** verrà creato con i seguenti permessi:

<code>
srw-rw-rw- 1 root clamav 0 Jun 16 12:08 /var/run/clamav/clamd.ctl
</code>

Per verificare che clamd stia girando con i permessi di root, è sufficiente richiamare **clamdscan** su **un file che non sia world-readable**:

<code>
chmod 600 /root/mail-test-eicar-antivirus.com 
clamdscan /root/mail-test-eicar-antivirus.com 
/root/mail-test-eicar-antivirus.com: Eicar-Signature FOUND
</code>

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:

<code>
clamdscan /root/mail-test-eicar-antivirus.com 
/root/mail-test-eicar-antivirus.com: lstat() failed: Permission denied. ERROR
</code>

La soluzione è utilizzare il parametro **%%--fdpass%%** di **clamdscan** che consente (solo lavorando su Unix socket) di passare il file descriptor al demone:

<code>
clamdscan --fdpass /root/mail-test-eicar-antivirus.com 
/root/mail-test-eicar-antivirus.com: Eicar-Signature FOUND
</code>