Messages in this thread | | | From | Johannes Weiner <> | Subject | Re: [malware-list] TALPA - a threat model? well sorta. | Date | Fri, 15 Aug 2008 07:12:56 +0200 |
| |
Hi,
david@lang.hm writes:
> On Thu, 14 Aug 2008, Arjan van de Ven wrote: > >> On Thu, 14 Aug 2008 22:04:00 -0400 >> Theodore Tso <tytso@mit.edu> wrote: >> >>> On Thu, Aug 14, 2008 at 06:44:33PM -0700, david@lang.hm wrote: >>>> could you do something like defining a namespace inside posix >>>> attributes and then setting up a mechanism in the kernel to alert >>>> if the attributes change (with the entire namespace getting cleared >>>> if the file gets dirtied)? >>> >>> According to Eric Paris the clean/dirty state is only stored in >>> memory. We could use the extended attribute interface as a way of not >>> defining a new system call, or some other interface, but I'm not sure >>> it's such a great match given that the extended attributes interface >>> are designed for persistent data. >>> >>> I agree that doesn't actually work very well for the tracker use case, >>> where you the clean/dirty bit to be persistent (in case the tracker is >>> disabled due to the fact you are running on battery, for example, and >>> then you reboot). >>> >> >> but we need a "give me all dirty files" solution, not a "is this file >> dirty" solution. >> >> I do not want a virus scanner to constantly have to poll the whole fs >> for dirty files ;-) > > I'm not sure. > > there are two situations (with the transition between them) > > 1. unscanned system, we want to do everything. (this happens > immediatly after a new signature file is deployed) > > here you do just want to filter out the files that have been scanned > from the list of everything, and you probably want to check at the > time of scanning the file in case it was opened (and scanned) in the > meantime. > > 2. mostly scanned system, we only want to scan files that have been > dirtied. > > here you don't need to scan everything, you only need to scan in two cases > > 2a. the file was dirtied (you learn about it and add it to the queue > of files to scan when you get around to it) > > 2b. an unscanned file is opened (the library detects that the file was > not marked approved by all the current scanners, so it invokes the > scanners on this file before completing the open, or copy for mmap, or > whatever)
2b could also be used as a general lazy scanning mechanism, no? If there is a new signature or the file is dirty or unknown, scan it. Always.
So this should all just be one case, no?
Hannes
| |