the kernel should not kick off a scan, instead it should check to see
an open/read should not kick off a scan, instead it should check to see if
the scan generation tag(s) are current should be enough (remember, you may
have more then one type of scanner running on the system)
definantly not the kernel. the intent of this is to keep linux from being
a storage repository for malware used by other systems. there is no need
to penalize linux-only apps by making them wait for a scan to take place.
If it lives in glibc there should be a way for linux apps that know that
they will not be exporting files to other systems to tell the library not
to do a scan.
for example, why should a log analysis program looking at apache logs be
forced to wait while multiple 'virii scanners' go through several gigs of
logs before it can start looking at them.
you are going to need some way to bypass the checks anyway so that you can
avoid the recursive case of the scanners triggering scans on files that
they open.
by keeping the scans all in userspace it also simplifies things greatly.
All the kernel should do is to maintain the tags with the file (posix
attributes??) and have a mechanism to clear them when the file is dirtied.
not a problem, in fact multiple agents scanning in parallel is a good
thing, it lets them all see the data with one pass through the disk.
they will all need to set different tags anyway (the fact that agent1
blessed the data doesn't mean that it's safe if agent2 hasn't done so)
this is not part of the threat model.
David Lang
--
