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

[Eric Paris <eparis@redhat.com>]

On Mon, 2008-08-18 at 18:25 +0100, Alan Cox wrote:
> > I think I'm going to stick with my special file in securityfs since it
> > makes it some simple to install the fd in the scanning process (as
> > opposed to netlink where I don't even know how it would be possible...)
> 
> AF_UNIX passes file handles just fine. I'm not sure netlink will help you
> here anyway - isn't it lossy under load ?

But the file being installed needs to be at least RD for AV/Indexer.
Particularly of interest to people here would be a file opened O_WRONLY
and then the indexer wouldn't have the ability to read the data that was
just written.  So we need a new FD, can't just send the old one.

I'd also assume that an HSM would need a WR file descriptor, which isn't
easy.  I've found that (through trial and error not understanding the
code) trying to make new descriptors for the new process have WR often
returned with ETXTBUSY....

I think I might just give RO file descriptors and if an HSM comes along
work with them to get WR fd's working....

> Also securityfs is more special purpose magic here - what does it have to
> do with a general purpose notifier API ? I'd actually generalise the
> notifier properly and go for a syscall.

Well, securityfs is really just a location for a bunch of interfaces.
The real 'magic' is that I defined my own read and write functions on a
special inode.

Lets assume a new syscall (and I know you tried to describe this too me
before but I can't remember it and I'm having some e-mail history
trouble) what would it look like?  A scanner constantly calls scan() to
block for data to be scanned?  So an AV, HSM, or indexer all would be
blocking in scan() just waiting for data?  How do they respond?  How is
it better, cleaner, or more general than a 'special' file they
read/write?

-Eric