[lkml]   [2008]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning
    On Mon, 2008-08-18 at 17:15 +0100, Alan Cox wrote:
    > > On async notification we fire a message to everything that registered
    > > 'simultaneously.' On blocking we fire a message to everything in
    > > priority order and block until we get a response. That response should
    > > be of the form ALLOW/DENY and should include "mark result"/"don't mark
    > > result."
    > No can do - you get stuck with recursive events with the virus checker
    > trying to stop the indexer from indexing a worm.

    My last interface was single leveled and was able to efficiently stop
    recursion by simply excluding all processes which were scanners. It was
    implemented as a flag in the task_struct. I could probably go the same
    route and just exclude all kernel initiated scanners from all scanning
    operations. I also included an interface for a process to be completely
    excluded, but given multi-level scanners I don't think an 'exclude all'
    is appropriate.

    I could add a separate interface for background/purely userspace
    scanners to register their level and only call scanners from the kernel
    with a lower level. Not sure what security I'd want to put around this

    > > read -> we have the ALLOW/mark result bit in core set so just allow.
    > Don't think we need this - SELinux can do that bit
    > > mtime update -> clear ALLOW/"mark result" bit in core, send async
    > > notification to userspace
    > Why via the kernel ?

    the single in core allow/deny bit is so that the vast majority of
    operations are completely free. Say we scan/index /lib/
    once. Do you really want every single read/mmap operation from then on
    to have to block waiting for the userspace caches of you HSM, your AV
    scanner, and you indexer? If all three tell the kernel they don't need
    to see it again and that information is easy and free to maintain, lets
    do it.

    > > The communication with userspace has a very specific need. The scanning
    > > process needs to get 'something' that will give it access to the
    > > original file/inode/data being worked on. My previous patch set does
    > file handle. Really you need to give the handle of the object because it
    > may not have a name or a meaningful inode number

    I think I'm going to stick with my special file in securityfs since it
    makes it some simple to install the fd in the scanning process (as
    opposed to netlink where I don't even know how it would be possible...)


     \ /
      Last update: 2008-08-18 19:41    [W:0.024 / U:16.696 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site