> On Oct 18, 2019, at 10:10 AM, G.W. Haywood via clamav-users > <clamav-users@lists.clamav.net> wrote: > > 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?
https://nvd.nist.gov/800-53/Rev4/control/RA-5 <https://nvd.nist.gov/800-53/Rev4/control/RA-5> 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: https://kb.cert.org/vuls/id/489481/ <https://kb.cert.org/vuls/id/489481/> It seemed like a poor solution, which was the impetus for creating this thread.
_______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
