lkml.org 
[lkml]   [2008]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TALPA - a threat model? well sorta.
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


\
 
 \ /
  Last update: 2008-08-15 03:33    [W:0.147 / U:1.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site