Re: virus scan application
Re: virus scan application
- Subject: Re: virus scan application
- From: Terry Lambert <email@hidden>
- Date: Mon, 6 Aug 2007 13:12:07 -0700
On Aug 5, 2007, at 7:07 PM, Jim Clause wrote:
All,
I'd appreciate a little bit more information about some points in this
thread, specifically what Terry said in points (3) and (4). I'd like
to implement a technique that's very similar to Time Machine.
Basically, a userland process would register with the kernel extension
and provide a pid. The kernel extension would call the userland
application whenever a vnode scope operation is performed by the pid.
The userland app would then create a backup of the file that's being
accessed. In this case I want to have blocking communication between
the kernel and the userland application so that I can create the
backup before the application can access the file.
Any such operation would need to be blocking, in fact, or you would be
giving them the answer before you had it yourself (assuming a user
space daemon is involved), which is impossible.
This is very similar to a hypothetical virus scanner so many of the
techniques should apply. I've read TN2127 and the list archives about
implementing a virus scanner and one question that's never been
definitively answered is how the kernel can block and then call out to
a user level application. In fact TN2127 says in the Listener Gotchas
section that the only foolproof method is the implement the scanner
completely in the kernel. Is this still the recommended approach? If
it is will I be able to implement my version of Time Machine?
The statement:
For example, an anti-virus scanner would particularly want to
scan files being opened by a thread running with elevated
privileges. In this case the only correct solution is for the
scanner to operate entirely within the kernel.
is incorrect; there is no reasonable way to do low level file I/O from
within a KEXT. This is an intentional design decision, and it's
unlikely to ever change. Since a virus scanner will, by necessity,
need to look at the contents of the files it is scanning, the
statement can't be correct, for obvious reasons.
The correct method involves my item (1):
(1) Exempting your virus scan daemon from such checks when
it makes requests, by having it register its process with your
KEXT
The caveat here is that you may not rely on other system services,
other than very simple system calls, if you want to avoid the
possibility of deadlock. So, for example, a virus scanner would not
want to link against Core Foundation, nor would it want to make name
resolution requests for network host names, etc.. In other words, you
limit yourself to functions in man(2) (system calls) and avoid those
in man(3) (library routines).
However, for the most part, the daemons in question that are contacted
by library routines behind your back run as "root", so the chance of
deadlock from that is more or less minimal, if you also follow the
recommendation that you exempt not only your virus scanner, but also
applications running as "root".
My personal opinion in this case is that you should limit your APIs
rather than doing this, as the threat to the system of a root process
triggering virus code is much higher than that for a non-root process
triggering the same code at a lower privilege level.
What this really boils down to is that I think that your daemon should
be in a state where it has all the information it needs in order to
make the decision in hand, rather than needing to go elsewhere to
obtain it; this also avoids the possibility of a deadlock, and is a
much more elegant approach to the deadlock problem.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden