[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0808180521010.12859@asgard.lang.hm>
Date: Mon, 18 Aug 2008 05:21:50 -0700 (PDT)
From: david@...g.hm
To: Pavel Machek <pavel@...e.cz>
cc: Arjan van de Ven <arjan@...radead.org>,
Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
malware-list@...ts.printk.net, andi@...stfloor.org,
riel@...hat.com, greg@...ah.com, tytso@....edu,
viro@...IV.linux.org.uk, alan@...rguk.ukuu.org.uk,
peterz@...radead.org, hch@...radead.org
Subject: Re: TALPA - a threat model? well sorta.
On Fri, 15 Aug 2008, Pavel Machek wrote:
>> Now this to me we have a few basic building blocks:
>> 1) We need an efficient mechanism to notify userspace of files that get
>> dirtied. Virus scanners will subscribe to this for the async dirty
>> scanning; indexing agents also will subscribe to this.
>
> ACK.
>
>> I think few people will disagree about this.
>>
>> Open questions now are
>> 4) do we have the kernel kick off an async scan in open() or do we have
>> glibc do this
>> 5) do we have the kernel do the sync scan on read/mmap/.. or do we have
>> glibc do this
>
>
> How does it work? Memory can still change after mmap; scanning at the
> mmap time is _NOT_ enough.
>
> You could do 'when app attempts to dirty memory, synchronously unmap
> it from all apps that have it mapped' and then do sync scan on
> pagefault time; but that sounds impractical.
what is the threat you are trying to defend against?
for some threats you are right, for others the scan at mmap time is
enough.
David Lang
--
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