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: <2629CC4E1D22A64593B02C43E85553030480743E@USILMS12.ca.com>
Date:	Tue, 5 Aug 2008 14:34:26 -0400
From:	"Press, Jonathan" <Jonathan.Press@...com>
To:	"Arjan van de Ven" <arjan@...radead.org>
Cc:	"Eric Paris" <eparis@...hat.com>, "Greg KH" <greg@...ah.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 linux interfaceforon access scanning

You're right...I am not talking about blocking at all -- which may be a
further indication that I am missing the specific point of this thread.

But be that as it may...  I don't want to have to use more than one
interface to get all the events I am interested in.  I want to register
as a client and listen, and get everything I need from the same place.


Also, it seems to me that for my purposes, close is discrete enough.  It
tells me that there is now something out there that should be looked at.


Jon



-----Original Message-----
From: Arjan van de Ven [mailto:arjan@...radead.org] 
Sent: Tuesday, August 05, 2008 2:28 PM
To: Press, Jonathan
Cc: Eric Paris; Greg KH; 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 linux
interfaceforon access scanning

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

> 
> However, I want to point out that scanning on close is still an
> integral part of AV protection, even if intercepting opens and execs
> theoretically catches everything.


but close is... very limited in value. Open is a discrete event
traditionally associated withh permission checks.
Close... not so.  (And if you mmap memory, you can then close the file
and still write to it via the mmap)

Lets ask it differently: what will you do if you find something nasty?
You can't fail the close... so why block for it?
And if you don't block for it... all you would need is an asynchronous
notification... something like... inotify

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ