Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
How about using techniques like LD_PRELOAD, anyway?
Why does it have to be a kernel module in the first place?
Critical Linux security API is still a kludge (Inquirer)
Posted Oct 23, 2006 15:06 UTC (Mon) by nix (subscriber, #2304)
Doing it globally with /etc/ld.so.preload is possible, but using this deactivates prelink and thus generally kills performance (there's no point in fixing it, as /etc/ld.so.preload is very much a debugging hack only and *not* meant for production use).
Putting it in the kernel (perhaps in a stacked filesystem a-la unionfs, once that gets into the kernel) is probably a better idea.
Posted Oct 23, 2006 15:19 UTC (Mon) by niner (subscriber, #26151)
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.
Posted Oct 23, 2006 15:38 UTC (Mon) by nix (subscriber, #2304)
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.
Posted Oct 23, 2006 18:29 UTC (Mon) by bluefoxicy (guest, #25366)
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.
Posted Oct 24, 2006 14:27 UTC (Tue) by arjan (subscriber, #36785)
(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)
Dakuzo doesn't work 100%
Posted Oct 23, 2006 15:59 UTC (Mon) by arjan (subscriber, #36785)
So not only is that approach they take a root-kit like kludge, it's not even nearly watertight. The don't (and fundamentally cannot) check reads and writes that are done via mmap() for example.
A fundamentally different technical solution is needed, and it probably is going to need changes all over the OS.
A few things that I think are needed:
* An easy, standard way for an application like firefox to ask "I'm about to save/open/... this file, please scan it for me and tell me it's ok". This is needed for Firefox, but also OpenOffice, Evolution and anything else that works with untrusted content. Preventing malware content from entering this system in the first place like this is always going to be better than finding it later on (that doesn't mean that the other one isn't needed per se, just that if you can filter it earlier that's obviously superior).
This way needs to be standardized (glibc?) and easy to use, while the admin can plug in policies and tools.
* SAMBA and NFS need a way of checking stuff before getting/sending it via the network. This may be able to use the previous thing, but maybe not.
* Wine and the other stuff this guy mentions should use the same hooks as in 1)
* If you want to do kernel level hooks, you CAN. They're called "LSM" today. LSM is superior to syscall hooking because it operates at the ACTION rather than at the ENTRY POINT. (this is similar to putting your money in a safe rather than putting a bigger lock on your door... the later case is vulnerable because a burglar can just come through the window). But even LSM doesn't solve the mmap() gap, that one is going to be fundamentally hard if not impossible to solve in a way that doesn't make performance totally suck
Posted Oct 23, 2006 16:28 UTC (Mon) by nix (subscriber, #2304)
scanning on write
Posted Oct 23, 2006 22:55 UTC (Mon) by skitching (subscriber, #36856)
If there are concerns about having to rescan a very large file which has had just a small piece modified then the monitoring layer (FUSE-based or other) could keep a list of modified blocks to be scanned on close. How about an in-kernel module that simply exposes a list of changed block ids which a user-mode module could then check on close?
Of course this is rather asymmetrical to the read scanning, which does need to be done as data is read in order to catch bad data on mounted filesystems such as NFS, so maybe it's not such a good idea..
Posted Oct 24, 2006 16:14 UTC (Tue) by nix (subscriber, #2304)
So yes, you have to scan on each write: at least on each write of a file opened by more than one process.
The Inq is wrong
Posted Oct 24, 2006 4:39 UTC (Tue) by gdt (subscriber, #6284)
SAMBA and NFS need a way of checking stuff before getting/sending it via the network. This may be able to use the previous thing, but maybe not.
Samba already has the Virtual File System API that can be used for virus scanning (and multilevel storage and other neat stuff). See samba-vscan for an implementation of a virus scanner which uses VFS.
Other applications which handle data on behalf of Windows systems have similar APIs. Sendmail's milter springs to mind. Milter is now in Postfix too, so we are seeking a common API emerge between the various mail transfer agents.
The Inq's complaint is that a API vital to virus scanning files before they are seen by a Window's host is missing. But since Samba, sendmail and other software which passed data to Windows systems have such APIs, what's the beef?
The article is a vendor whinge to a naive journalist dressed up with a page-hit-seeking headline.
Posted Oct 24, 2006 11:53 UTC (Tue) by job (guest, #670)
Of course, evil code could relocate specific portions in data files, and by directly calling the kernel to execute them bypass the check. But this would be trivial by mmaping those parts in executable space anyway.
It's not very different in nature from self-encrypting code. I think the scanners need to treat them the same way, by checking for the decrypting/execing/mmaping code to begin with. The in-kernel hook described sounds like a flawed design no matter how you look at it, and I am not the least surprised it's difficult to convince the kernel devs to let it in.
Posted Oct 24, 2006 16:19 UTC (Tue) by nix (subscriber, #2304)
And of course shared libraries are mmap()ed in by ld.so (well, so is the executable, but you can tell what that's called statically: finding out the total set of shared libraries a program will use is impossible in the general case because of dlopen(), and indeed anything reimplementing dlopen() itself via mmap(), or via open() and read() into a prepared mmap()ed area.)
It has many of the same fundamental flaws as does digsig: it'll stop everyone but the determined attackers it's most useful to stop. (I'd like digsig to work as well but unfortunately it's one of those tools that only works until a single malware author works around it).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds