Realtime is tough to do without the kernel extensions, for example I wrote a stand along daemon to do this using inotify, but what I learned is that not only is inotify limited (you have to set the maximum number of objects to modify in the kernel, its got a default thats pretty low, so once you go over it no other objects are monitored), but that its reliability varies MASSIVELY from kernel to kernel. It was so unreliable I could just race condition it with malware, upload, block, upload, block, upload, not blocked. It was so inconsistent between the vanilla kernels that there wasnt even consistency repeating it, so sometimes it was clean, other times it wasnt. Seems dangerous to put out something that rested on such an unreliable (and unpredictably unreliable) foundation, we couldnt even say "kernel X is bad, kernel Y isnt), it was crazy inconsistent.
Which is why we instead decided we needed absolute positive control through the kernels access control system. The new fanotify stuff shows promise too, and that as well is all kernel level, so theres a compromise system in the works that may work with non-ASL kernel, but they will have to include the new mainline fanotify capabilities, but older kernels absolutely do not. So unfortunately, even though I know some people have put out inotify based clamav tools, they are totally unreliable, and thats the best tool for the job if you arent going to use something dazuko (or possibly the upcoming fanotify capabilities).
I'm wide open to ideas, but thats actually how we started, and it just didnt meet our reliability requirements (its a shame too, because I put in a LOT of work on the daemon).
Atomicorp - Security For Everyone
Co-Author of Troubleshooting Linux Firewalls.