lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning
Date
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.


\
 
 \ /
  Last update: 2008-08-05 20:11    [W:0.765 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site