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.040 / U:154.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site