On Sáb, 2013-03-02 at 10:26 +0100, Michael Scherer wrote: > 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. Hi, some ideas, If you do a re-review of the package I can help you on review, please CC directly to me . I have a server with qmail and Fedora 17 based on qmailrocks and now just http://qmail.jms1.net/patches/combined-details.shtml Clamav package works with it without patches :) I'm thinking document it, my email server solution but don't had much time, also now that qmail is public domain, it use and integrated a few packages of Fedora. About what you wrote: Don't understand the concern on so must security, I use it under a router so this port are close to exterior and in side my LAN don't see a problem to have a tcp port, neither have completely untrusted email. Best regards, -- Sérgio M. B. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
