Le vendredi 01 mars 2013 à 00:24 +0000, Sérgio Basto a écrit :
Hi, I also use clamav as daemon and I use fedora package, recently I
upgrade the box, that use clamav, to Fedora 17. I had to do a new
clamd.service based on what exist, so here it
is /usr/lib/systemd/system/clamd.service :
Description = clamav server (clamd) daemon
After = syslog.target nss-lookup.target network.target
Type = simple
ExecStart = /usr/sbin/clamd -c /etc/clamd.conf --nofork=yes
Restart = on-failure
PrivateTmp = true
given that clamav is a security sensitive package ( ie, we feed it with
all kind of crap coming from network ), wouldn't it be interesting to
investigate using :
afaik, clamav use socket to communicate, so this could help to mitigate
exploit that download from the network, or just a attacker using a
exploit to attack a inside ressource.
not sure if clamav is multiprocess when run as daemon, should be checked
too. This would permit to mitigate some exploits, ie, not able to
fork/exec would block "let's spawn a shell bound to port XXX".
- DeviceAllow= and just allow /dev/null or /dev/zero I guess. the
reasoning are on the page of systemd
, in short, if someone
using code injection to attack a device for local privileges escalation
from clamav, this would mitigate some exploit.
- CapabilityBoundingSet=~CAP_SYS_PTRACE , and maybe more stringent
restriction, again, this requires some tests. This one is harder to
setup since we need lots of runtime tests, and since clamav is not
running as root, I am not sure this bring much, when compared to the
work it may requires.
While some of theses are surely already blocked by selinux, some people
unfortunately tend to disable it, so we should think about defence in
And if that work fine, we can start to apply this idea to others daemons