Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon accessscanning

[tvrtko . ursulin]

Rik van Riel wrote on 06/08/2008 16:46:04:

> On Wed, 6 Aug 2008 11:33:23 -0400
> "Press, Jonathan" <Jonathan.Press@xxxxxx> wrote:
> 
> > Even so, I don't think your extreme examples are really parallel to 
what
> > we do.  Personally, I think that scanning on open, exec and close is 
not
> > excessive. 
> > 
> > And in fact, we do go out of our way to avoid scanning when it really
> > isn't necessary.  For example, that's the reason that we want a cache 
--
> 
> Disks are slow and files are getting larger by the day.
> 
> We can do a lot better than scanning a whole file.  A mechanism
> that can notify programs about what file changed and what byte
> range in the file changed can reduce scanning overhead by only
> needing to scan the part of the file that changed.

It is much more advanced than that, really. I don't know if ever a whole 
file is read and in 99% it is just a tiny part of it. I don't know what I 
am allowed to disclose and also it is not my area of expertise, but if you 
are interested in how detection actually works maybe we can talk off list 
and put you in touch with some other people here.

It is also wrong to think that you can scan only what has changes because 
that bit may be harmless itself but present a final part of a malware 
puzzle.
 
> More importantly, getting info on which bytes in a file changed
> will also help backup programs and disk indexing programs.

True, but Nick mentioned some huge issues with access after close and 
munmap in one of your previous postings. It sounds to me that would be a 
huge VM/filesystem work to actually enable things like this.
 
> What we need to work on is making sure that the interfaces
> that go into the kernel are useful not just for anti-virus
> programs, but also for other software.

I definitely agree with that.

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/