linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon 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 for Android: free password hash cracker in your pocket

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

Message-Id: <1217961574.27684.129.camel@localhost.localdomain>
Date:	Tue, 05 Aug 2008 14:39:34 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	"Press, Jonathan" <Jonathan.Press@...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

On Tue, 2008-08-05 at 11:27 -0700, Arjan van de Ven wrote:
> 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)

Thankfully my implementation will invalidate that close time check and
caching result.  It does the invalidating the same place we update mtime
and my understanding is that mmap has been updating mtime for quite a
while now.  So again, it might not be perfect, but that situation should
get caught the next time around.  I see close time checking as more of a
performance win and as a way to help close some of the length bad
information could exist than anything since its done in a non-blocking
path.

I think we all agree that open is the most interesting time for scanning
operations, but as Jonathan points out there is some value (even if not
perfect value) in looking at closes as well.

> 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

I actually already have an async non-blocking close notification built
in.  Instead of waiting for a userspace response we just queue the close
notification and move along.  When userspace gets around to it scanning
and allow/deny caching can then take place at a later time.

-Eric

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