no problem
there are multiple approaches to this (i.e. a policy issue that belongs in
userspace)
1. you trust the machines the media comes from, so you trust the scan
results.
2. you don't trust the remote machines and you then either extend this
model into a per filesystem approach (and invalidate/increment/change the
genration key on the new media that's loaded), or you tryand make the
generation key be cryptograhicly random, so that the odds of the
generation key on the media being valid for the machine it's plugged into
is next to impossible (generating a good GUID as the generation key as the
signature/scanner is loaded would be pretty close to random for example)
you could do a LSM hook, but in many (if not most) cases it makes sense to
have the tags stored across boots, so if you do it through LSM you have to
figure out how/where to store it. if you can put it in posix extended
attibutes most filesystems will handle it for you.
will it? if it's already empty trying to clear it should be cheap. it's
like maintaining the dirty bit on a chunk of memory.
this still leaves a window between the time you last check that the dirty
flag is still set, while you clear the dirty flag and set the clean flag
that modifications could be made to the file and it will still get marked
clean. if this race is small enough this feature can be skipped
I missed that part of the discussion. what I was reading was that people
were saying that it worked for everything except staticly compiled
binaries and knfsd.
why would it not make sense to have the checking in a userspace library
(libmalware could be seperate or loaded from glibc or be part of glibc,
depending on your level of concern
the kernel detects writes to mmap and dirties the file (clearing the
flags), the next time the file is accessed it will be re-scanned (assuming
that the background scanner doesn't get there first) do the checks at the
time of mmap, don't try to do it for each memory read.
as for two programs having the file open at the same time and the risk of
passing bad data from one to the other. the risk model specifies we are
not trying to protect against running programs. shared mmap is a
communications channel between them just like a pipe, we aren't trying to
protect inter-process communication (just like we aren't trying to protect
network communication)
there are probably better answers, but I'm leaving that up to the folks
who want to write all the scanning tools. I'm just trying to help by
assembling the ideas different people mentioned during this thread into a
minimaly invasive set of hooks that are useful beyond the AV space into
other things that are needed (like HSM, indexing, or for that matter a
backup daemon could gather the list of files it needs for an incrimental
backup by listening for the kernel to tell it every file that changes
instead of needing to scan TB worth of filesystems for them)
David Lang
--
