From: david@lang.hm
To: Arjan van de Ven <arjan@infradead.org>
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,
tytso@mit.edu, 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: Thu, 14 Aug 2008 18:31:03 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.1.10.0808141821150.13400@asgard.lang.hm> (raw)
In-Reply-To: <20080813103951.1e3e5827@infradead.org>
On Wed, 13 Aug 2008, Arjan van de Ven wrote:
> 2) We very likely should have a mechanism for a userspace app to
> request a scan on a file, both sync or async (O_SYNC flag?). This is
> useful regardless because it allows the source of many things to do the
> right thing.
> 3) we need a mechanism in the kernel to track "scanned with generation
> X of signatures" that invalidates on any dirty operation. The syscall
> from 2) will use this as a cache to be quick.
>
> 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
the kernel should not kick off a scan, instead it should check to see
an open/read should not kick off a scan, instead it should check to see if
the scan generation tag(s) are current should be enough (remember, you may
have more then one type of scanner running on the system)
> 5) do we have the kernel do the sync scan on read/mmap/.. or do we have
> glibc do this
definantly not the kernel. the intent of this is to keep linux from being
a storage repository for malware used by other systems. there is no need
to penalize linux-only apps by making them wait for a scan to take place.
If it lives in glibc there should be a way for linux apps that know that
they will not be exporting files to other systems to tell the library not
to do a scan.
for example, why should a log analysis program looking at apache logs be
forced to wait while multiple 'virii scanners' go through several gigs of
logs before it can start looking at them.
you are going to need some way to bypass the checks anyway so that you can
avoid the recursive case of the scanners triggering scans on files that
they open.
by keeping the scans all in userspace it also simplifies things greatly.
All the kernel should do is to maintain the tags with the file (posix
attributes??) and have a mechanism to clear them when the file is dirtied.
> I think this is where the whole debate is about now.
>
> And a few hard ones
> 6) how do we deal with multiple scanning agents in parallel
not a problem, in fact multiple agents scanning in parallel is a good
thing, it lets them all see the data with one pass through the disk.
they will all need to set different tags anyway (the fact that agent1
blessed the data doesn't mean that it's safe if agent2 hasn't done so)
> 7) how do we prevent malware from pretending to be a virus scanner
this is not part of the threat model.
David Lang
next prev parent reply other threads:[~2008-08-15 1:31 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
2008-08-15 1:31 ` david [this message]
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.0808141821150.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=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).