Messages in this thread | | | Date | Mon, 18 Aug 2008 10:13:16 -0700 (PDT) | From | david@lang ... | Subject | Re: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning |
| |
On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote on 18/08/2008 16:31:48: > >>> Huh? I was never advocating re-scan after each modification and I even > >>> explicitly said it does not make sense for AV not only for performance > but >>> because it will be useless most of the time. I thought sending out >>> modified notification on close makes sense because it is a natural > point, >>> unless someone is trying to subvert which is out of scope. Other have >>> suggested time delay and lumping up. >> >> You need a bit more than close I imagine, otherwise I can simply keep > the >> file open forever. There are lots of cases where that would be natural >> behaviour - eg if I was to attack some kind of web forum and insert a >> windows worm into the forum which was database backed the file would >> probably never be closed. That seems to be one of the more common attack >> vectors nowdays. > > Yes, I agree that modification notifications are needed in some cases. > >>> Also, just to double-check, you don't think AV scanning would read the > >>> whole file on every write? >> >> So you need the system to accumulate some kind of complete in memory set >> of 'dirty' range lists on all I/O ? That is going to have pretty bad >> performance impacts and serialization. > > No, I was just saying scanning is pretty smart, it's not some brute force > method of scan all data that is there. It has a file type detection and > what and how to scan is determined by that. If a file does not resemble > any file type I don't think it gets scanned. For example take couple of > gigabytes of zeros and try to scan that with some products. I don't think > they will try to read the whole file.
trying to include details of where each file was updated means that you can't just set a single 'dirty' flag for the file (or clear the 'scanned' flags), you instead need to detect and notify on every write.
this is a HUGE additional load on the notification mechansim and the software that recieves the notifications.
just sending "fix X was scanned and now isn't" is going to be bad enough, you _really_ don't want to do this for every write.
David Lang
| |