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


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