[clamav-users] Stop clamdscan from stepping on itself?

Paul Kosinski clamav-users at iment.com
Fri Oct 18 15:45:36 EDT 2019


"of course you can't even really trust brand new drives any more"

Do you mean unreliability, or active insecurity? If the latter, any
examples? (Of drives per se, not hardware systems or subsystems.)

And what can any AV do about it?



On Fri, 18 Oct 2019 18:10:17 +0100 (BST)
"G.W. Haywood via clamav-users" <clamav-users at 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 at 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?  Do the regulations
> specify the minimum acceptable probability (*) of finding something
> malicious (given such a thing is in fact there) with your choice of
> scanning tool?  And acceptable characteristics of the infrastructure
> supporting the chosen scanning engine, the frequency of updates, the
> methods to be used by said engine, and the security systems in place
> which prevent compromise of all that?  If not, the bald imprecation
> (for that's all it is) "scan daily" seems to be completely pointless.
> 
> (*) I'd estimate for ClamAV you're looking at about 30% on a good day,
> and if it's a zero-day exploit, obviously, zero percent, for anything,
> not just ClamAV.  If you don't like these numbers, read my occasional
> posts about it in the archives of this list, going back several years.
> 
> > 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.
> 
> > 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).
> 
> > 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.
> 
> Do these log messages actually matter?  As I mentioned to someone else
> recently, there's always syslog-ng.
> 
> Is there a reason you think something nasty might be able to get into
> this filesystem that you're, er, religiously scanning daily?  And, if
> there is, would it not make more sense to deal with that, instead of
> waiting for it to get in, and then playing hide'n'seek with it?  For
> once it's in, all bets are off and you'd best buy some new drives (of
> course you can't even really trust brand new drives any more).  FWIW
> the last time I saw a compromised Linux box was almost twenty years
> ago, but I know it does still happen because people will insist on a
> pretty-looking blog, or forum, or whatever, and then they don't seem
> to bother patching things, even when the exploit's been in the news
> for a week.  Even when they're a computer security company.
> 
> Do these government regulations say anything about patching software?
> Judging by the number of ransomware outbreaks in US government bodies
> I guess maybe not.  (You seem to be on PDT, so I guessed again. :)
> 


More information about the clamav-users mailing list