From: Arjan van de Ven <arjan@infradead.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Eric Paris <eparis@redhat.com>,
linux-kernel@vger.kernel.org, malware-list@lists.printk.net,
andi@firstfloor.org, riel@redhat.com, greg@kroah.com,
viro@ZenIV.linux.org.uk, alan@lxorguk.ukuu.org.uk,
peterz@infradead.org, hch@infradead.org
Subject: Re: TALPA - a threat model? well sorta.
Date: Wed, 13 Aug 2008 11:21:49 -0700 [thread overview]
Message-ID: <20080813112149.2fda0fa4@infradead.org> (raw)
In-Reply-To: <20080813181549.GH8232@mit.edu>
On Wed, 13 Aug 2008 14:15:49 -0400
Theodore Tso <tytso@mit.edu> wrote:
> On Wed, Aug 13, 2008 at 10:39:51AM -0700, Arjan van de Ven wrote:
> > 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).
>
> Something else to think about is what happens if the file is naturally
> written in pieces. For example, I've been playing with bittorrent
> recently, and it appears that trackerd will do something... not very
> intelligent in that it will repeatedly try to index a file which is
> being written in pieces, and in some cases, it will do things like
> call pdftext that aren't exactly cheap. A timeout *can* help (i.e.,
> don't try to scan/index this file until 15 minutes after the last
> write), but it won't help if the torrent is very large, or the
> download bitrate is very slow. One very simple workaround is to
> disable trackerd altogether while you are downloading the file, but
> that's not very pleasant solution; it's horribly manual.
>
> Most of this may end up being outside of the kernel (i.e.,some kind of
> interface where a bittorrent client can say, "look this file is still
> being downloaded, so it's don't bother scanning it unless some process
> *other* than the bittorrent client tries to access the file". And
> maybe there should be some other more complex policies, such as the
> bittorrent client explicitly telling the indexer/scanner that the file
> is has been completely downloaded, so it's safe to index it now.
>
> verification --- is very much a policy question where different system
> administrators will come down on different sides about what should and
> shouldn't be allowed --- and therefore this kind of policy decision
> should ****NOT**** be in the kernel.
exactly. Even more, since this is async work, the scheduling of the
order of work also is a policy.. and userland is again the right place
for that.
>
> > For efficiency the kernel ought to keep track of which files have
> > been declared clean, and it needs to track of a 'generation' of the
> > scan with which it has been found clean (so that if you update your
> > virus definitions, you can invalidate all previous scanning just by
> > bumping the 'generation' number in whatever format we use).
>
> We have an i_version support for NFSv4, so we have that already as far
> as the version of the file. We can have a single bit which means
> "block on open" that is stored on a file, and some kind of policy
> which dictates whether or not any modification to the file contens
> should automatically set the bit.
>
> 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.
> 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)
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
next prev parent reply other threads:[~2008-08-13 18:22 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 [this message]
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
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=20080813112149.2fda0fa4@infradead.org \
--to=arjan@infradead.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=eparis@redhat.com \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list@lists.printk.net \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=tytso@mit.edu \
--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).