linux-kernel - RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2629CC4E1D22A64593B02C43E855530304AE4AE3@USILMS12.ca.com>
Date:	Wed, 6 Aug 2008 08:10:53 -0400
From:	"Press, Jonathan" <Jonathan.Press@...com>
To:	"Rik van Riel" <riel@...hat.com>
Cc:	"Greg KH" <greg@...ah.com>,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Eric Paris" <eparis@...hat.com>, <linux-kernel@...r.kernel.org>,
	<malware-list@...ts.printk.net>,
	<linux-security-module@...r.kernel.org>
Subject: RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

-----Original Message-----
From: Rik van Riel [mailto:riel@...hat.com] 
Sent: Tuesday, August 05, 2008 8:51 PM
To: Press, Jonathan
Cc: Greg KH; Arjan van de Ven; Eric Paris; linux-kernel@...r.kernel.org;
malware-list@...ts.printk.net; linux-security-module@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a
linuxinterfaceforon access scanning

On Tue, 5 Aug 2008 14:38:23 -0400
"Press, Jonathan" <Jonathan.Press@...com> wrote:

> However, I will say that while preventing infections from arriving is
> not foolproof, doing a scan-on-close with the option to delete or
> quarantine an infected file goes a long way.

How can you, as a security professional, argue for a security measure
that you know is flawed, when there is a mailing list full of people
willing to help figure out what a working security measure would look
like?

Yes, abandoning some of the old DOS anti-virus security model may cause
work, but surely that will be worth it if it leads to a more secure
system?

[JON PRESS]  I hesitate to join back in the discussion, because so far I
haven't been very successful.  I know that my level of technical depth
is not at all the equal of just about everybody else in this
conversation.  That's not my job and I don't claim to have the answers
to all the questions that are being raised.

However...  This question about arguing for a flawed security technique
is a good one, and in a way it gets to the heart of the philosophy of
security.  Scan-on-close is admittedly incomplete as an anti-virus tool.
But I don't agree that that make it flawed.   It is part of a repertoire
of techniques for preventing malware from residing on a machine.

Let's take a simplistic and unrealistic example.  Let's suppose that you
knew that there were 20 applications on your machine that had buffer
overflow vulnerabilities that could be exploited, and you had a fix for
18 of them.  Would you decide not to apply the fixes, because that meant
that there would still be 2 left -- and because theoretically there is a
way to prevent all buffer overflows from being exploited and there is a
mailing list full of people trying to figure out how to do it.

I think if it as being like the Sieve of Eratosthenes.  The further down
you go, the more numbers drop out.  In AV scanning, each step of the way
removes some percentage of the harmful files, and closes the window of
time that they have to operate or migrate.  Or maybe it's like spraying
insecticide when there is an outbreak of some deadly mosquito-borne
illness.  Without getting into the political issues about spraying,
because this is JUST AN EXAMPLE -- would you not spray because 5% of the
bugs would still be left behind?  Wouldn't you then spray again, because
you wipe out another 95%?

If this were not the case, why would so many of our customers run
scheduled system scans on a regular basis in addition to scanning on use
and scanning on close?  There are several reasons, including the
constant evolution of malware, the possibility that a machine's
protection was temporarily disabled for some reason, etc.  The point is
that catching malware as close to the time it is written as possible is
a net gain that adds to the overall level of protection.

Hopefully, in addition to discussing the particular question that was
raised in Rik's email, this also sheds some light on how I look at the
overall problem -- i.e., from a higher more conceptual level of
functionality and value, rather than the low-level technical specifics.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/