Subject: Re: TALPA - a threat model? well sorta.
Date: Wednesday 13th August 2008 19:29:22 UTC (over 9 years ago)
On Wed, Aug 13, 2008 at 03:02:48PM -0400, Eric Paris wrote: > I never suggested putting a scanner in kernel. Sound like you want the > "allow don't cache" response from your userspace scanner while this is > going on. The kernel doesn't need to be making decisions about when to > send events, nor should userspace tell the kernel not to send events. > Its up to whatever the scanner is to agree not to actually do any > scanning... And if the system isn't running a virus checker, but just a file indexer (ala tracker), it shouldn't go to userspace at all. In that case all that is necessary is an asynchronous notification. Also something else that is needed is support for multiple clients. (i.e., what happens if the user runs two virus checkers, or a virus checker plus a hierarchical storage manager driving a tape robot, or all of the above plus trackerd --- where some clients need to block open(2) access, and some do not need block open(2) --- and in the case of HSM, ordering becomes important; you want to retrieve the file from the tape robot first, *then* scan it using the virus checker. :-) > No. How in the heck can some out of kernel database store information > about what inodes have been scanned in any even slightly sane way? And > people think the race between open and read is too large and you suggest > moving clean/dirty marking to a userspace database? I MUCH prefer my > (and it sounds like arjan agrees) clean/dirty versioned flag in inode. Don't ask me; I think most AV checkers for linux are security theater and not very much use (other than making money for the AV company's shareholders) anyway. I thought you were the one who wanted to record information about which version of the virus db a particular file had been scanned against. The place where I can see this being useful is what happens you get a new virus DB, and so you need to start scanning all of the files in your 5TB enterprise file server --- and then the system crashes or it needs to be taken down for scheduled maintenance. You want to have *some* off-line database for storing this information, since it would be silly to want to have the first thing that happens after a new virus DB gets downloaded is to interate over the entire filesystem, clearing a persistent the "clean" bit --- that would take *forever* on a 5TB filerserver; and what happens if you crash in the middle of clearing the "clean" bit.. And if the system gets shutdown in the middle of the scan, you need some way of remembering which inodes have been scanned using the "new" db, and which ones haven't yet been scanned via the new virus db. All of this should be kept in userpsace, and is strictly speaking Not Our Problem. I'm just arguing that there should be absolutely *no* support in the kernel for solving this particular problem, since the question of whether a file has been scanned with a particular version of the virus DB is purely a userspace problem. - Ted