Messages in this thread |  | | Subject | Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning | | From | Eric Paris <> | | Date | Wed, 20 Aug 2008 15:26:07 -0400 |
| |
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.
|  |