User Tools

Site Tools


doc:appunti:linux:sa:clamav_permissions

This is an old revision of the document!


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 reinstallazione del pacchetto clamav-daemon.

Esecuzione senza privilegi di root

Ovviamente la soluzione ottimale è lasciare che clamd venga eseguito senza privilegi di root.

doc/appunti/linux/sa/clamav_permissions.1592302206.txt.gz · Last modified: 2020/06/16 12:10 by niccolo