[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] RE: mount/umount events?

From: John Ogness
Subject: Re: [Dazuko-devel] RE: mount/umount events?
Date: Wed, 16 Feb 2005 16:36:16 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

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:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]