Hi there,
On Fri, 18 Oct 2019, Ian via clamav-users wrote:
On Oct 18, 2019, at 12:02 AM, G.W. Haywood via clamav-users <clamav-users@lists.clamav.net> wrote:
On Thu, 17 Oct 2019, Ian via clamav-users wrote:
/usr/bin/clamdscan -m -i --no-summary /
Don't do that.
Government regulations require that I scan the entire filesystem
daily --
Which government is this, and which regulations?
This is one of the controls I have to work with— it’s not the only one since there are overlapping controls from other regulations. It was determined that we needed to do daily scans by auditors familiar with these regulations. Please don’t blame the victim.
I've already excluded the folders that contain pseudo files.
That's good - although if you'd mentioned it earlier it would be much
easier to believe. The main trouble is that things like your command
to scan '/' get written into internet folklore like the 'mx' mechanism
in your SPF record and then everybody does it, because that's what it
says on the Internet. It's really much better if you actually think
about it a bit first.
I think this is unfair — I specifically asked about a specific temp file that clamav was creating and then choking on. The title of this thread wasn’t asking why I’m getting ACCESS DENIED errors all over the place — it specially called out one particular problem I do not see when I’ve used other antivirus products in linux, or even when I do a “sudo clamscan —temper /tmp /tmp” on the same system.
Also, it seems like bad advice to omit scanning the folder most
likely to find a payload from a malicious actor (because file
permissions tend to be lax in /tmp), but I could be misinterpreting
what "Don't do that" means.
You are indeed misinterpreting. I didn't advise "don't scan /tmp",
and it seems to me to be a little churlish to accuse me of giving bad
advice when (a) I didn't give that advice and (b) I'm actually trying
to help. And if you're worried about file permissions in /tmp you are
presumably capable of doing something about it (although there might
be good reason to be cautious when you start along that kind of path).
Again, I feel this is unfair — I called out the one temp file that clamav was having issues with — you edited that out from your response, while tersely responding with what amounts to “Don’t do that, RTFM.” How else could that be reasonable interpreted?
This doesn't seem like a difficult problem...
I think I'd be disappointed if I told clamd to scan everything in a
directory tree, and it didn't try to do that. On the other hand it's
not the sort of thing I'd generally do, unless the tree was a client's
Windows filesystem that I'd mounted temporarily to take a peek at it.
Read the man page for clamd, especially the bit that talks about where
it should store its temporary files.
This dances around the problem I’m trying to solve. Why does it matter where the temporary files are created? When does it make sense to scan its own temp files? Why does this only happen with clamdscan and not clamscan?
Do these log messages actually matter? As I mentioned to someone else
recently, there's always syslog-ng.
They do, and as I mentioned in the original post, it’s a difficult problem to filter out because malicious actors could create similarly named files to take advantage of these filters. This is an attack vector that was recently used against Cylance:
It seemed like a poor solution, which was the impetus for creating this thread.