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

[Rave it]

>  At today's FESCo meeting there were two tickets which had the
> end
>  result of needing to have new maintainers and comaintainers for some
>  packages:
>  
>  == https://fedorahosted.org/fesco/ticket/1028 ==
>  
>  tor package was reassigned to a new maintainer.  Former maintainer
>  dropped ownership of his other packages.  Those are now orphaned and
>  in need of a new owner.  Note to potential new maintainers: although
>  not mandatory, you may want to open an optional re-review request as
>  the spec files for some of these may be very out of sync with the
>  current Fedora Packaging Guidelines
>  
>  * clamav 
I've added me as comaintainer to clamav and i'm willing to take
ownership if it is orphoned.
Shure, i will do a new review request because i want to reorganized the
package like it is for epel.
Fedora's version is total user unfriendly, ie. needed to copy
configuration files by hand and no default daemon configuration.
I used the epel version for a long time for myself, because you need
only installation and enable the the daemon, that's all.

Wolfgang

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

[Sérgio Basto]

On Qui, 2013-02-28 at 14:58 +0100, Rave it wrote: 
>  > At today's FESCo meeting there were two tickets which had
> the end
>  > result of needing to have new maintainers and comaintainers for some
>  > packages:
>  > 
>  > == https://fedorahosted.org/fesco/ticket/1028 ==
>  > 
>  > tor package was reassigned to a new maintainer.  Former maintainer
>  > dropped ownership of his other packages.  Those are now orphaned and
>  > in need of a new owner.  Note to potential new maintainers: although
>  > not mandatory, you may want to open an optional re-review request as
>  > the spec files for some of these may be very out of sync with the
>  > current Fedora Packaging Guidelines
>  > 
>  > * clamav
>  I've added me as comaintainer to clamav and i'm willing to take
>  ownership if it is orphoned.
>  Shure, i will do a new review request because i want to reorganized the
>  package like it is for epel.
>  Fedora's version is total user unfriendly, ie. needed to copy
>  configuration files by hand and no default daemon configuration.
>  I used the epel version for a long time for myself, because you need
>  only installation and enable the the daemon, that's all. 
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


Cheers,
-- 
Sérgio M. B.

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

[Michael Scherer]

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

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

[Sérgio Basto]

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.

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

[Michael Scherer]

Le vendredi 08 mars 2013 à 04:15 +0000, Sérgio Basto a écrit :

>  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.  
Usually, clamav interact with the rest of the world by reading files
sent by anybody on the internet using smtp, so it is processing
potentially hostile input, even with all closed ports on the firewall.


For exemple, if there is a flaw in the parser of exe parser of clamav
and i send you a cooked email with a exe that trigger the exploit, with
a hardened setup, clamav would 
1) have no network access ( thus preventing me to use it to spam or
attack the lan )
2) not have possibility to spawn a shell or anything ( thus requiring me
to write or find a more complex exploit, and preventing me from spawing
a process that would survive a restart of clamav )
3) would not be able to use a local exploit using something in /dev, in
the unlikely event such a exploit exist at the same time than a clamav
issue.

So if someone is running with all protections ( fw, selinux down ), they
would still cause issues to some exploits. That's not a magic solution,
but better than nothing.

That's defence in depth. Some people may not have firewall setup or
selinux setup, or some people may be attacked from the inside of the LAN
and have disabled selinux on the whole server because "that was written
on the web". So while a firewall and selinux prevent some type of attack
( and is useful to have of course ), it can be good to have others type
of protections in case of. 

-- 
Michael Scherer