Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[Eric Paris <eparis@redhat.com>]

On Wed, 2008-08-20 at 10:33 -0700, david@lang.hm wrote:

> if the system package manager says the syslogd binary doesn't match the 
> checksum that it has recorded should it be prevented from running? (a 
> strict policy would say no, but the sysadmin may have recompiled that one 
> binary and just wants a warning to be logged somewhere, not preventing the 
> process from running)

My belief is that if you choose to run a file scanner and that file
scanner gets the answer wrong you need to look at the file scanner.
There shouldn't be arbitrary overrides.  If you don't accept the results
of the scanner what's the point?  Tell you package manager scanner that
you changed it.

> without the kernel support to clear the flags when the file is dirtied how 
> can these programs trust the xattr flags that say they scanned the file 
> before?

I don't understand what you mean about trust.  This is an argument for
kernel support now?  What is it that you say needs and what doesn't need
it?  Can you explain exactly what your perfect solution from top down?

> I'm not saying that xattr is the only way to store the info, it just seems 
> like a convienient place to store them without having to create a 
> completely new API or changing anything in on-disk formats.

And I saying we don't actually need any of this and if it is actually
needed by someone in the real world they can easily build their own
solution on top of my generic interface.  I'm not making the assertion
it is race free and don't think it is possible without making every
sequential (hahahaha.)  But I claim in the face of normal operation it's
fine.  My interface, as proposed, is very generic.  Much more so than
what I think you are trying to describe.  I couldn't make mine more
minimal or broad.