From: david@lang.hm
To: tvrtko.ursulin@sophos.com
Cc: Eric Paris <eparis@redhat.com>,
alan@lxorguk.ukuu.org.uk, andi@firstfloor.org,
Arjan van de Ven <arjan@infradead.org>,
hch@infradead.org, linux-kernel@vger.kernel.org,
malware-list@lists.printk.net,
malware-list-bounces@dmesg.printk.net, peterz@infradead.org,
viro@ZenIV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model? well sorta.
Date: Thu, 14 Aug 2008 18:37:31 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.1.10.0808141835020.13400@asgard.lang.hm> (raw)
In-Reply-To: <20080814094701.A65372FE89E@pmx1.sophos.com>
On Thu, 14 Aug 2008, tvrtko.ursulin@sophos.com wrote:
> Eric Paris wrote on 13/08/2008 19:57:44:
>
>>> It's clear from the protection model that you described that on 'read'
>>> you want to wait until the scan is done before you give the data to
> the
>>> process asking for it... and that's totally reasonable: "Do not give
>>> out bad data" is a very clear line in terms of security.
>>>
>>> for the "dirty" case it gets muddy. You clearly want to scan "some
>>> time" after the write, from the principle of getting rid of malware
>>> that's on the disk, but it's unclear if this HAS to be synchronous.
>>> (obviously, synchronous behavior hurts performance bigtime so lets do
>>> as little as we can of that without hurting the protection).
>>> One advantage of doing the dirty case async (and a little time
> delayed)
>>> is that repeated writes will get lumped up into one scan in practice,
>>> saving a ton of performance.
>>> (scan-on-close is just another way of implementing "delay the dirty
>>> scan").
>>> Based on Alans comments, to me this sounds like we should have an
>>> efficient mechanism to notify userspace of "dirty events"; this is not
>>> virus scan specific in any way or form. And this mechanism likely will
>>> need to allow multiple subscribers.
>>
>> I'm certainly willing to go down the inotify'ish path for async
>> notification of 'dirty' inodes instead of implement my own async
>> mechanism if I can find a way to do it.
>
> Do I understand correctly that everyone agrees scanning whenever an inode
> gets dirty would be a terrible thing for performance?
>
> Another thing we have here is that malware could not be neccessariliy
> identified until the very last write (one example where it will always be
> the case are PDF files (I think)).
>
> So the whole question is at which point should be performing an async
> scan. Close seems like a natural point which should be ideal for majority
> of applications, I don't see how any time-based lumping/delaying scheme
> can be better than close?
all you need is the ability to mark a file as 'dirty', and some way for
programs that are interested in dirty files learning about it later and
decideing to do a scan. if the file gets dirtied again after they do they
scan they will need to do another one (this is a classic trade-off between
the 'security' of looking for things quickly or 'efficiancy' of only
looking when you don't think they will change again. in other words,
policy -> userspace)
David Lang
next prev parent reply other threads:[~2008-08-15 1:37 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-13 16:36 TALPA - a threat model? well sorta Eric Paris
2008-08-13 16:24 ` Alan Cox
2008-08-13 16:47 ` Eric Paris
2008-08-13 16:37 ` Alan Cox
2008-08-13 17:00 ` Eric Paris
2008-08-13 19:59 ` Alan Cox
2008-08-13 21:24 ` [malware-list] " Press, Jonathan
2008-08-13 21:13 ` Alan Cox
2008-08-13 21:35 ` Rik van Riel
2008-08-13 21:23 ` Alan Cox
2008-08-15 3:25 ` Eric Paris
2008-08-15 20:16 ` Jan Harkes
2008-08-15 22:05 ` Arjan van de Ven
2008-08-17 23:19 ` Eric Paris
2008-08-17 23:26 ` Arjan van de Ven
2008-08-17 21:11 ` David Collier-Brown
2008-08-18 15:33 ` Alan Cox
2008-08-18 16:43 ` Rik van Riel
[not found] ` <20080819071416.GA14731@elf.ucw.cz>
2008-08-19 16:10 ` HSM (was Re: [malware-list] TALPA - a threat model? well sorta.) Rik van Riel
2008-08-19 19:20 ` Pavel Machek
2008-08-19 20:33 ` Rik van Riel
2008-08-20 17:03 ` Pavel Machek
2008-08-13 17:07 ` TALPA - a threat model? well sorta Christoph Hellwig
2008-08-14 13:00 ` Arnd Bergmann
2008-08-13 16:57 ` Greg KH
2008-08-13 17:39 ` Arjan van de Ven
2008-08-13 18:15 ` Theodore Tso
2008-08-13 18:21 ` Arjan van de Ven
2008-08-14 9:18 ` tvrtko.ursulin
2008-08-13 19:02 ` Eric Paris
2008-08-13 19:29 ` Theodore Tso
2008-08-13 21:15 ` [malware-list] " Press, Jonathan
2008-08-14 9:30 ` tvrtko.ursulin
2008-08-14 12:03 ` Press, Jonathan
2008-08-14 12:27 ` tvrtko.ursulin
2008-08-15 14:31 ` Pavel Machek
2008-08-14 13:24 ` Theodore Tso
2008-08-14 13:48 ` Eric Paris
2008-08-14 15:50 ` Theodore Tso
2008-08-14 17:29 ` Eric Paris
2008-08-14 19:17 ` Theodore Tso
2008-08-14 19:20 ` Eric Paris
2008-08-14 19:34 ` Christoph Hellwig
2008-08-14 19:41 ` Theodore Tso
2008-08-14 20:20 ` Christoph Hellwig
2008-08-14 21:21 ` J. Bruce Fields
2008-08-14 23:34 ` Theodore Tso
2008-08-19 21:43 ` J. Bruce Fields
2008-08-15 1:44 ` david
2008-08-15 2:04 ` Theodore Tso
2008-08-15 3:41 ` Arjan van de Ven
2008-08-15 5:05 ` david
2008-08-15 5:12 ` Johannes Weiner
2008-08-15 5:28 ` david
2008-08-15 5:36 ` david
2008-08-15 4:48 ` david
2008-08-15 8:51 ` Alan Cox
2008-08-15 14:37 ` Pavel Machek
2008-08-13 18:57 ` Eric Paris
2008-08-13 21:39 ` Arjan van de Ven
2008-08-14 14:12 ` Eric Paris
2008-08-14 15:57 ` Arjan van de Ven
2008-08-15 10:07 ` Helge Hafting
2008-08-15 10:37 ` Peter Zijlstra
2008-08-15 13:10 ` [malware-list] " Press, Jonathan
2008-08-15 13:18 ` douglas.leeder
2008-08-15 17:04 ` Theodore Tso
2008-08-15 18:09 ` Press, Jonathan
2008-08-18 10:09 ` Helge Hafting
2008-08-18 10:14 ` Peter Zijlstra
2008-08-18 10:24 ` tvrtko.ursulin
2008-08-18 10:25 ` douglas.leeder
2008-08-15 16:25 ` david
2008-08-15 16:30 ` Press, Jonathan
2008-08-15 17:33 ` david
2008-08-15 17:40 ` Press, Jonathan
2008-08-15 17:47 ` david
2008-08-15 18:06 ` Valdis.Kletnieks
2008-08-15 20:05 ` david
2008-08-15 20:17 ` Theodore Tso
2008-08-15 18:17 ` Press, Jonathan
2008-08-15 20:08 ` david
2008-08-18 10:02 ` Helge Hafting
2008-08-15 10:44 ` tvrtko.ursulin
2008-08-14 9:46 ` [malware-list] " tvrtko.ursulin
2008-08-14 13:46 ` Arjan van de Ven
2008-08-15 1:37 ` david [this message]
2008-08-15 1:31 ` david
2008-08-15 16:06 ` Pavel Machek
2008-08-18 12:21 ` david
2008-08-18 13:30 ` Pavel Machek
2008-08-19 0:03 ` david
2008-08-13 18:17 ` Andi Kleen
2008-08-13 18:21 ` H. Peter Anvin
2008-08-13 18:24 ` Arjan van de Ven
2008-08-13 18:40 ` Eric Paris
2008-08-14 0:18 ` Mihai Donțu
2008-08-14 11:58 ` [malware-list] " Press, Jonathan
2008-08-14 12:34 ` Mihai Donțu
2008-08-14 0:14 ` 7v5w7go9ub0o
2008-08-14 2:25 ` 7v5w7go9ub0o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.1.10.0808141835020.13400@asgard.lang.hm \
--to=david@lang.hm \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list-bounces@dmesg.printk.net \
--cc=malware-list@lists.printk.net \
--cc=peterz@infradead.org \
--cc=tvrtko.ursulin@sophos.com \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).