Messages in this thread | | | Date | Wed, 06 Aug 2008 07:31:47 -0400 | From | David Collier-Brown <> | Subject | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon access scanning |
| |
Peter Dolding wrote: > My main issue is TALPA, dazuko and so on of Anti-Virus Filesystem > monitoring are all going to break anyhow when > http://lwn.net/Articles/251224/ Credentials get added and common > filesystem caching gets added. > > You want to change a permissions on a file/object before its opened. > So does the Credential user space daemon on file systems that cannot > store secuirty information. We only really need 1 location in the > source base for this. Expand Credentials slightly to allow anti > viruses to operate by by problem. Even better when FS-Cache can sit > on top of Credentials correctly no need for anti virus software to > have independent caching of blocked and allowed files. FS-Cache picks > a large amount of this up. > > Basically TALPA, dazuko and so on of Anti-Virus Filesystem monitoring > don't fit in the future design of Linux. All they will be is > duplication of a existing interface. A interface that complete avoids > the stacking issue.
Then in a real sense you've solved much of their problem for them (;-)) After this comes engineering, so that they can re-use the scanning mechanisms they already have, but from a different caller.
The requirements are probably that they know - is this an open for read or write (somewhat less time-sensitive)? - is the data present, or do we have to wait? - if so, for what? as of the time they start looking at the file. Having a race-free mechanism using credentials and RCU is, IMHO, A Really Good Thing.
Another thing they and we will likely need is a way to discover if a file is inacessable due to an AV operation, and if the time it has been inacessable is less than or equal to a scanning upper bound by file size or beyond it. The latter is for repair of broken state introduced by the AV process failing.
--dave
> > Peter Dolding > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
-- David Collier-Brown | Always do right. This will gratify Sun Microsystems, Toronto | some people and astonish the rest davecb@sun.com | -- Mark Twain cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#
| |