Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 787233

Summary: app-antivirus/clamav: clamonacc doesn't work out of the box
Product: Gentoo Linux Reporter: Jesús P Rey (Chuso) <gentoo>
Component: Current packagesAssignee: Antivirus Team <antivirus>
Status: UNCONFIRMED ---    
Severity: normal CC: ab4bd, genzilla, jstein, kangie, proxy-maint
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Jesús P Rey (Chuso) 2021-04-30 20:52:31 UTC
I wanted to try app-antivirus/clamav with clamonacc USE flag for on-access file scanning.

Starting the RC script seems to work:

$ sudo /etc/init.d/clamonacc start
 * Starting clamonacc ...          [ ok ]

But when I noticed trying to access an EICAR test file doesn't trigger any issue, I checked it and so clamonacc was not actually running.

Trying to run from the command line the same command the RC script runs shows that clamonacc indeed fails to start:

$ sudo /usr/sbin/clamonacc --foreground
ERROR: Clamonacc: at least one of OnAccessExcludeUID, OnAccessExcludeUname, or OnAccessExcludeRootUID must be specified ... it is reccomended you exclude the clamd instance UID or uname to prevent infinite event scanning loops

The command exited with a failure status, but the RC script is not able to notice it:

$ echo $?
2

There is a line for OnAccessExcludeUname in /etc/clamd.conf, but it's commented:

#OnAccessExcludeUname clamav

Uncommenting it allows clamonacc to start.

Maybe the ebuild should uncomment it? At least when clamonacc is enabled.

Although this would allow clamonacc to start, it will still do nothing because there are no paths configured by default to be scanned on access:

$ sudo /usr/sbin/clamonacc --foreground
ERROR: ClamInotif: Please specify at least one path with OnAccessIncludePath

But I'm not so sure it's also the task of the ebuild to configure that. Maybe just a pkg_postinst einfo?

Note that the correct option is not necessarily OnAccessIncludePath as stated in the message and it could be OnAccessMountPath if DDD is enabled: https://www.clamav.net/documents/on-access-scanning

Even after fixing all that,  clamonacc functionality is limited, but I think this is more an upstream issue.

clamonacc uses clamd to scan the files, which by default runs as clamav user, so it will fail to scan any file clamav user doesn't have access to.
It would be enough for a virus with setting the permissions of its payload file to 600 to bypass on-access scan.

That could be worked around by making clamd run as root, but that would require setting OnAccessExcludeUname to root, which would mean files accessed by root wouldn't be scanned, which is also a security issue.

I guess a better workaround could be setting a recursive ACL for clamav user to be able to access any file, but that sounds a bit like cracking nuts with a sledgehammer.
Comment 1 Michael Orlitzky gentoo-dev 2021-04-30 22:12:52 UTC
(In reply to Jesús P Rey (Chuso) from comment #0)
> 
> The command exited with a failure status, but the RC script is not able to
> notice it:
> 
> $ echo $?
> 2
> 

This is probably a real bug that we could fix, but upstream has rejected the patches for OpenRC and is going to rewrite the entire build system in the next release (and require Rust...), so I'm personally not very inclined to waste any more time trying to improve things for them.

While not directly responsible, the OpenRC script has to jump through hoops because of this upstream issue: https://bugzilla.clamav.net/show_bug.cgi?id=12595


> But I'm not so sure it's also the task of the ebuild to configure that.
> Maybe just a pkg_postinst einfo?

Yeah, I agree that it sucks, but there's really no way around it: you have to tell clamonacc what you want it to scan. Security concerns (and not wanting to crash the system) make it impossible for us to guess at these settings. An einfo is a good idea, or it might be better if the service script reported the problem and suggested a solution because that's harder to overlook.


> Even after fixing all that,  clamonacc functionality is limited, but I think
> this is more an upstream issue...

You're absolutely right, but there's already an "easy" solution to this problem. If you run clamd on a local socket and if you start clamonacc with the --fdpass flag, then clamonacc will pass a file descriptor to clamd rather than a path name, and that allows clamd to read it without any special privileges.

Where this goes wrong is that "--fdpass" is a command-line flag for clamonacc, but the socket is configured somewhere else, in clamd.conf. So we can't decide in the OpenRC script whether or not we should use --fdpass. IIRC there's an upstream bug about this somewhere. (I wonder if we can enable this unconditionally even if the user has a TCP/IP socket configured.) 

Clamonacc is still pretty new and unpolished in my opinion. People are just starting to use it and report all the bugs that arise. A lot of these problems will sort themselves out as time goes on.
Comment 2 Thomas Raschbacher gentoo-dev 2021-05-01 12:33:50 UTC
I agree that an einfo in pkg_postinst that clamonacc requires further configuration would definitely be a good idea.