Messages in this thread | | | From | Nick Piggin <> | Subject | Re: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning | Date | Wed, 6 Aug 2008 04:08:05 +1000 |
| |
On Tuesday 05 August 2008 07:00, Eric Paris wrote: > Please contact me privately or (preferably the list) for questions, > comments, discussions, flames, names, or anything. I'll do complete > rewrites of the patches if someone tells me how they don't meet their > needs or how they can be done better. I'm here to try to bridge the > needs (and wants) of the anti-malware vendors with the technical > realities of the kernel. So everyone feel free to throw in your two > cents and I'll try to reconcile it all. These 5 patches are part 1. > They give us a working able solution. > > >From my point of view patches forthcoming and mentioned below should > > help with performance for those who actually have userspace scanners but > also could presents be implemented using this framework. > > > Background > ++++++++++ > There is a consensus in the security industry that protecting against > malicious files (viruses, root kits, spyware, ad-ware, ...) by the way > of so-called on-access scanning is usable and reasonable approach. > Currently the Linux kernel does not offer a completely suitable > interface to implement such security solutions. Present solutions > involve overwriting function pointers in the LSM, in filesystem > operations, in the sycall table, and other fragile hacks. The purpose > of this project is to create a fast, clean interface for userspace > programs to look for malware when files are accessed. This malware may > be ultimately intended for this or some other Linux machine or may be > malware intended to attack a host running a different operating system > and is merely in transit across the Linux server. Since there are > almost an infinite number of ways in which information can enter and > exit a server it is not seen as reasonable to move these checks to all > the applications at the boundary (MTA, NFS, CIFS, SSH, rsync, et al.) to > look for such malware on at the border. > > For this Linux kernel interface speed is of particular interest for > those who have it compiled into the kernel but have no userspace client. > There must be no measurable performance hit to just compiling this into > the kernel. > > Security vendors, Linux distributors and other interested parties have > come together on the malware-list mailing list to discuss this problem > and see if they can work together to propose a solution. During these > talks couple of requirement sets were posted with the aim of fleshing > out common needs as a prerequisite of creating an interface prototype. > > Collated requirements > +++++++++++++++++++++
I suspect that what people actually want is a requirement of what it is they are trying to do. Not a list of demands on the kernel that they think are needed to implement what they think is the right way to solve some problem that they define.
> 5. Define which filesystems are cacheable and which are not
This is practically impossible to do completely without rewriting a lot of code (which will never be accepted). I don't see why it is needed though as the filesystem cache is supposed to be kept coherent with disk.
| |