| |||||||||||||
Critical Linux security API is still a kludge (Inquirer)Critical Linux security API is still a kludge (Inquirer)Posted Oct 23, 2006 15:19 UTC (Mon) by niner (subscriber, #26151)In reply to: Critical Linux security API is still a kludge (Inquirer) by nix Parent article: Critical Linux security API is still a kludge (Inquirer)
Checking every access to every file is a giantic waste of resources and the reason why Windows is so unbearably slow, as soon as an anti virus product is installed.
Why check a file 15 times, when it didn't change? Using knotify to only check files that are new or have changed seems to be a much better idea to me. Besides, nowadays checking websites and emails seems to be much more important than files on the hard disk.
(Log in to post comments)
Critical Linux security API is still a kludge (Inquirer) Posted Oct 23, 2006 15:38 UTC (Mon) by nix (subscriber, #2304) [Link] It also means that the things opening the files *block* until the dazuko-using application has gated access, which *at best* turns open() from a syscall requiring two ring transitions to one requiring four ring transitions and two context switches!
Doing this sort of thing using inotify is a total waste of time in the presence of network filesystems, SANs, and other filesystems that may be written by other than the local system.
But then this whole thing is a total waste of time anyway. Probably an LD_PRELOADed wrapper *is* the right thing: a wrapper wrapped specifically around WINE and those (very rare) other things that are actually at risk from Windows malware. Normally a clamav milter or something similar can do a better job anyway.
Critical Linux security API is still a kludge (Inquirer) Posted Oct 23, 2006 18:29 UTC (Mon) by bluefoxicy (guest, #25366) [Link] Actions like read() and mmap() can go through FUSE; and if you mmap() a file on a FUSE file system the kernel has to ask FUSE what to do with it. Once the filter extensions hit FUSE mainline (Miklos says they will), you'll be able to reliably determine when a file has changed.
For network file systems like NFS or SMB, you'll have to scan accessed data each time it's pulled over; but incremental scanning is possible. Picture scanning an executable that adds viral code to .text called by _main(). The relocation pages are pulled over, relocations are done, functions in .init are run, some of .text is pulled over, _main() is entered. Now _main() tries to execute virus in a page that hasn't yet been accessed. As that page is brought over, it is scanned for a virus, which is located; the system refuses to give that page to the application, and the application segfaults.
Of course the whole incremental scanning part is conjecture; a proof of concept implementation would be nice.
Critical Linux security API is still a kludge (Inquirer) Posted Oct 24, 2006 14:27 UTC (Tue) by arjan (subscriber, #36785) [Link] fuse doesn't do good enough mmap for virus scanners.fuse only gets to see the mmap page (when written to) at the final commit to the fs; but before that it has been in the VM for a LONG time, and visible to all other apps that have that file open. So the virus evil can already have taken place....
(and before you say "but the other app scans on open", at the time that app opened the file it may well not have been infected yet; many apps have .so files open as mmap for a really long time, weeks if not months)
|
|||||||||||||