Critical Linux security API is still a kludge (Inquirer) [LWN.net]

Critical Linux security API is still a kludge (Inquirer)

Posted Oct 23, 2006 18:29 UTC (Mon) by bluefoxicy (guest, #25366)
In reply to: Critical Linux security API is still a kludge (Inquirer) by niner
Parent article: Critical Linux security API is still a kludge (Inquirer)

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.

(Log in to post comments)

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)