Messages in this thread | | | Date | Fri, 15 Aug 2008 09:35:13 +0100 | From | Alan Cox <> | Subject | Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning |
| |
> So if that is the threat model, then the only thing libmalware.so > doesn't solve is knfsd access, and it should be evaluated on that
And static binaries, and other kernel modular file I/O done on behalf of applications, and making a library work well which is *hard*, and labelling and scalability, and sharing a cache between users, and aggregating events across processes .. and a few other things.
You have a lot of shared state here.
> So let's be real clear, up front, what the threat model is, and avoid > changing the model around to rule out solutions that don't fit the > initially preconceived one. That's how you get to the TSA > confiscating water bottles in airport security lines.
I don't think this is useful. I don't actually care what the virus folks want to implement. I would rather see useful general purpose interfaces that are practical and make sense. I cdon't really care whether people use the write() system call to do sensible or dumb things. What we should care about is the write syscall.
There seem so far to be two independent requests
* Noticing a file has recently changed, possibly with information about changes and possibly being able to aggregate/time that for scalability. This has a need to be able to accurately reference which file. This is needed for good content indexing, and virus people want it for certain kinds of scanning (post write, background etc). Doing this solely as a final close notifier seems to be insufficient (as it may never close).
* Being able to pause an open pending some action. Examples include HSM and dubiously some kinds of virus check. Problems here include the fact it can only meaningfully be done for first open (which is fine for HSM) and that the notion of an exclusive open, or of repeated clearly defined open/read-write/close/done sequences are actually quite foreign to Unix like systems.
We shouldn't need to care what people do with good interface. What matters is in your airport example is that at the infrastructure level there is a point you can choose to do scanning and we agree where. Whether people use this to provide a Starbucks or goons with rubber gloves who take away babies milk is an application layer problem.
Alan
| |