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 : > > [Unit] > Description = clamav server (clamd) daemon > After = syslog.target nss-lookup.target network.target > Before= spamassassin.service > > [Service] > Type = simple > ExecStart = /usr/sbin/clamd -c /etc/clamd.conf --nofork=yes > Restart = on-failure > PrivateTmp = true > > [Install] > WantedBy=multi-user.target 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 : - PrivateNetwork=yes 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. - LimitNPROC=1 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 http://0pointer.de/blog/projects/security.html , 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 depth. And if that work fine, we can start to apply this idea to others daemons as well. -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel