Maintainers wanted for packages from 2013-02-27 FESCo Meeting

Sérgio Basto sergio at serjux.com
Fri Mar 8 04:15:54 UTC 2013


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.



More information about the devel mailing list