Re: [malware-list] scanner interface proposal was: [TALPA] Introlinux interface for access scanning
From: david
Date: Thu Aug 21 2008 - 17:20:39 EST
On Thu, 21 Aug 2008, douglas.leeder@xxxxxxxxxx wrote:
Eric Paris wrote on 2008-08-20 16:15:21:
At the moment I'm leaning towards a separate async notification system
for open/mtime change/close which will be a fire and forget notification
system with no access control mechanism.
A second, although very similar, mechanism will block on read/mmap
(although I'm not so sure how to handle O_NONBLOCK without a kernel
fastpath/inode marking that actually gets used, this is really a serious
design issue with putting this at read/mmap. I don't think we are ready
to give up on O_NONBLOCK for S_ISREG altogether just yet are we?) and
provide access control. I also plan to include open() in the
blocking/access control based on a /proc tunable. If applications can't
handle EPERM at read/mmap they can get it at open and suffer the
perf/blocking hit needlessly on open/stat sequences.
I think these are excellent ideas.
The kernel really does have to keep some record if it's going to do any
scanning from read() calls, it can't go to userspace each time to check
if a file is cached.
(It might be the single open file descriptor that's marked though)
if you say that the hooks are in the kernel then it does make sense to try
and have the checking of the cached state done in the kernel.
this will mean that the kernel will have to have some way of knowing which
programs it should block when the check fails and which ones it should let
go ahead anyway.
O_NONBLOCK is then handled nicely, and we can avoid ever blocking that
client process (which given they're trying non-blocking IO is probably
a good thing).
I don't see how this follows.
David Lang
--
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/