Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 56805 - move clamav socket for <= app-antivirus/clamav-0.74. init script issues raised
Summary: move clamav socket for <= app-antivirus/clamav-0.74. init script issues raised
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Antivirus Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-12 09:56 UTC by Darren Spruell
Modified: 2004-10-08 12:25 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darren Spruell 2004-07-12 09:56:01 UTC
Suggestions for the protection of the communication socket used by clamav, if possible. For security it has been recommended to protect the socket located at /tmp/clamd from all users other than clamav user. Default behaviour for the ebuild is to put the socket at /tmp/clamd, open to everyone. The default config file enables an option as "LocalSocket /tmp/clamd".

One way to rememdy this would be to create a directory at e.g. /var/run/clamav/ writable by the clamav user, perms 0600, and the socket file within that. 

Reproducible: Always
Steps to Reproduce:
1. emerge clamav
2. configure /etc/clamav.conf, enable default option for local socket
3. ls -l /tmp/clamd

Actual Results:  
Clam socket open to the world:

srwxrwxrwx  1 clamav  clamav  0 Jul 12 10:24 /tmp/clamd

Expected Results:  
There is arguable security benefit in protecting the socket from non-clamav users.
Comment 1 Darren Spruell 2004-07-12 14:09:19 UTC
I may have misunderstood the way Clam works.. if a user can't access the socket file, clamdscan won't work, for example..?
Comment 2 Daniel Black (RETIRED) gentoo-dev 2004-07-24 08:05:52 UTC
I'd suggest the socket be in /var/run/clamav to be consistant to where samba vfs plugin expects to see it (/usr/share/doc/samba-3.0.5-r1/samba-vscan-0.3.5/vscan-clamav.conf.gz) (and make it a bit more LFS maybe). Placing the socket in tmp may mean this is open to symlink attacks.

Looking in the /etc/clamav.conf file the FixStaleSocket options indicates that it removes stale sockets. This means the init script doesn't need to.

So the socket isn't open to a DoS it probably should be writable by a group clamav. Things like samba (and mailprograms) should be part of this group and user runable programs may like clamdscan may have a group setuid (although this introduces a DoS capability).

Should there be a generic group e.g virus that means all programs with generic virus plugin capability can be part of this group and communicate to any virusscanner?

The clamd is run as root (athough probably doesn't need to be). Why is a log file created in the init.d script to a given permission? There is no enforcement of consistancy between /etc/conf.d/clamd and /etc/clamav.conf
Comment 3 Daniel Black (RETIRED) gentoo-dev 2004-07-24 17:16:33 UTC
Security - any comments on comment #3?
Comment 4 Dan Margolis (RETIRED) gentoo-dev 2004-07-24 20:21:37 UTC
I assume you mean Comment #2. :P

A couple points: 

1) You're only open to a symlink attack if ClamAV doesn't check the file for existence before overwriting it (I have no idea if it does or doesn't, but hopefully it does). 

2) Am I right in assuming that (with the exception of the first point regarding symlink attacks) the only risk here is of a local user removing the communication socket, requiring a restart of ClamAV? And am I right in my understanding that if the ebuild were altered to allow rw permissions by the group clamav, other packages that use clamav may have to be altered to run as a user who is a member of that group (if this is already default behavior, everything should be peachy with your suggested fix, but if not, will users end up breaking things when they emerge -u clamav if they aren't provided with updates to the other dependent packages?). 

Seems to be a reasonably minor security risk--unless point 1, no data loss or likely more than temporary e-mail outage, etc--but it probably should be fixed. 
Comment 5 Thomas Raschbacher gentoo-dev 2004-07-30 18:43:22 UTC
will have a look at this..
Comment 6 Thomas Raschbacher gentoo-dev 2004-10-08 12:25:44 UTC
is this still an issue with 0.75.1 and/or 0.80_rc3 ?