Re: RE: mount/umount events?

Tikka, Sami wrote:
> Is there anything in dazuko that guarantees that the file cannot be changed
> between the time a scan daemon finds the file clean and the time the file is
> actually read or executed? I guess not. I agree that the window of
> vulnerability is very small but it still exists.

With the current implementation of Dazuko, the window will always exist. 
There are currently alternatives that are able to close this window, but 
only under certain circumstances:

http://www.filesystems.org/docs/avfs-security04/avfs.pdf


> So, in my opinion we have a problem if we have evil programs writing to files
> and keeping them open and nice programs reading them at the same time.

Yes, you are right. This is why Dazuko needs to move into the VFS layer. 
Hooking all the system calls isn't going to fix it. This is why I want to 
stop doing things wrong and start spending my energy to do things right.

Once Dazuko is in the VFS layer, we can add all kinds of events/mechanisms 
so that the window is 100% closed. This is my goal. This is a *REQUIREMENT* 
if Dazuko is to become a security solution.


> I agree it does not 100% solve my problem but like I said above, I do not
> think it is possible to solve it *totally*. I would be happy get it almost
> there, like 90% or 95%. Of course, I am happy if you can prove me wrong. I'd
> like nothing better than to have a 100% correct solution.

We can solve it, but not with system call hooks (or LSM).


> As I see it, I have 2 choices:
> 
> A) Remove the cache and instruct customers to scan only the minimum set of
> files in order to maintain usable performance.

This would be a safe option for now.

On a side note, as far as I know about your product you are only registering 
one process with Dazuko. This hurts performance TREMENDOUSLY. I noticed last 
night that ClamAV's Clamuko is doing this too. It is important that you 
register lots of processes so that the operating system can work in 
parallel. I would like to send patches to ClamAV to help them out, but I am 
not (yet) sure if I am allowed (since I work for an anti-virus company 
myself). Registering multiple dameons is VERY important. That's why the 
feature is there (and has been since version 1.0).


> B) Implement mount/umount events and ship a version of dazuko that is
> incompatible with your official dazuko.

I have no problems with this option. Dazuko is currently not *that* popular, 
so I think you will have no problem with customers using a customized 
Dazuko. Just make sure they know it is customized in case your extensions 
have bugs/problems.


> C) Write a new driver (let's call it "fazuko" :) that implements mount/umount
> events (and perhaps the link follow event on Linux 2.6). This way I could use
> your version of dazuko and still get the couple of extra events from fazuko.

This is also an option, but seems like it would be a lot more maintenance 
work (separate device, separate processes or threads, lots of duplication of 
Dazuko code).


If you want a quick and dirty 95% "solution", then go with "B". But I 
personally feel that "A" is a safer solution for customers.

John Ogness

-- 
Dazuko Maintainer