Message-Id: <1218654168.3540.115.camel@localhost.localdomain>
Date:	Wed, 13 Aug 2008 15:02:48 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	andi@...stfloor.org, riel@...hat.com, greg@...ah.com,
	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 Wed, 2008-08-13 at 14:15 -0400, Theodore Tso 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.
> 
> But what this points out is that if you want a good solution, (a) it
> probably shouldn't all be in the kernel, since trying to get all of
> this complexity into the kernel will be painful, and (b) the policy
> about whether or not a bittorrent client should be allowed to say,
> "it's OK not to check the file until it's completely downloaded, even
> if I am handing out pieces to other people over the network --- after
> all the entire file has its own SHA checksum for data integrity
> 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.

I never suggested putting a scanner in kernel.  Sound like you want the
"allow don't cache" response from your userspace scanner while this is
going on.  The kernel doesn't need to be making decisions about when to
send events, nor should userspace tell the kernel not to send events.
Its up to whatever the scanner is to agree not to actually do any
scanning...

> However, questions of which version of virus database was used to scan
> a particular file should be stored outside of the filesystem, since
> 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
> going to be messy.  So better that this be done in userspace, and that
> this information be stored in some on-disk database.

No.  How in the heck can some out of kernel database store information
about what inodes have been scanned in any even slightly sane way?  And
people think the race between open and read is too large and you suggest
moving clean/dirty marking to a userspace database?  I MUCH prefer my
(and it sounds like arjan agrees) clean/dirty versioned flag in inode.

-Eris

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