linux-kernel - Re: 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 10:18:02 +0100
From:	tvrtko.ursulin@...hos.com
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	alan@...rguk.ukuu.org.uk, andi@...stfloor.org,
	Eric Paris <eparis@...hat.com>, greg@...ah.com,
	hch@...radead.org, linux-kernel@...r.kernel.org,
	linux-kernel-owner@...r.kernel.org, malware-list@...ts.printk.net,
	peterz@...radead.org, riel@...hat.com,
	Theodore Tso <tytso@....edu>, viro@...IV.linux.org.uk
Subject: Re: TALPA - a threat model?  well sorta.

Arjan van de Ven wrote on 13/08/2008 19:21:49:

> > However, questions of which version of virus database was used to scan
> > a particular file should be stored outside of the filesystem, since
> 
> well I was assuming we only store this in memory (say in the inode) and
> just rescan the file if we destroy the in memory inode.
> I don't see the need for this to be persistent data; in fact I assume
> (Eric, please confirm) that this data is not *supposed* to be
> persistent.

Correct.

> > each product will have its own version namespace, and the questions of
> > what happens if a user switches from one version checker to another is
> 
> yes that's a hard question; what if you have 2 virus scanners active.
> 
> (they could register a version of the database with the kernel, and the
> in kernel version-cookie could be a hash of all registered versions I
> suppose.. if anything changes ever we just rehash and scan as if we
> have to do that)

It is in fact really simple with the proposed inode versioning approach. 
Any client which wants to invalidate the cache just needs to bump the 
global version number which will force a rescan on next access.

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

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