linux-kernel - Re: [malware-list] TALPA - a threat model? well sorta.

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]

Date:	Thu, 14 Aug 2008 09:48:33 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Theodore Tso <tytso@....edu>
Cc:	tvrtko.ursulin@...hos.com, alan@...rguk.ukuu.org.uk,
	andi@...stfloor.org, Arjan van de Ven <arjan@...radead.org>,
	hch@...radead.org, linux-kernel@...r.kernel.org,
	malware-list@...ts.printk.net,
	malware-list-bounces@...sg.printk.net, peterz@...radead.org,
	viro@...IV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model?  well sorta.

On Thu, 2008-08-14 at 09:24 -0400, Theodore Tso wrote:
> On Thu, Aug 14, 2008 at 10:30:56AM +0100, tvrtko.ursulin@...hos.com wrote:
> > The thing is the idea never was for clean-dirty "database" to be 
> > persistent but to have the same lifetime as the inode (in memory one). And 
> > once the cache/database gets invalidated re-scanning happens on-demand so 
> > the 5TB problem does not exist. Concerns about multiple clients where 
> > every has a different versioning scheme are also not relevant with the 
> > proposed versioning scheme (see my reply to Arjan).
> 
> So in essence, what I hear you saying is that all AV products want to
> work in a mode where the moment the inode falls out of the inode
> cache, and we lose the "clean" bit, when the inode is brought back
> into the cache, it will be scanned again.  That is, the "clean" bit is
> never persistent, and never needs to be stored in memory.

There needs to be a way to say that an inode in cache needs to be
rescanned.  3 states this flag can be.  Clean, Dirty, Infected.  The
current talpa solution involves a global monotomically increasing
counter every time you change virus defs or make some "interesting"
change.  If global == inode flag we are clean.  If global == negative
inode flag we are infected.  if global > inode flag we are dirty and
need a scan.

> That seems fair; if it turns out there is an AV product that wants to
> optimize this a bit further, as long as we provide a persistent inode
> version/generation number, they can always do their own persistent
> database in userspace.

exporting i_version might be useful for better userspace caching,
although I've yet to see any reasonable description of how a userspace
database can map between data on disk and what they have in userspace.
How can a userspace process, given 2 file descriptors know they are
actually the same thing on disk?

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