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

[Tikka, Sami]

>-----Original Message-----
>From: John Ogness [mailto:address@hidden 
>Sent: Thursday, February 10, 2005 12:28 AM
>To: Tikka, Sami
>Cc: address@hidden
>Subject: Re: mount/umount events?
>
>
>It would seem to me that if you are caching the results of 
>scanning file 
>content, that you should use more than device/inode pairs for 
>determining if the cache should be invalidated. Dazuko doesn't detect 
>when files are modified, only when they are open/closed (and for Linux 
>2.6 only opened). I fail to see how knowing about mount/umount makes 
>your solution safer. You have the same problem even if 
>mounting doesn't 
>take place.

Dazuko can detect if a file is opened for writing. I can remove a cache entry
whenever a file is opened for writing or the file is removed. That takes care
of most of the usual cases of file access. Then there's umount, which
invalidates a whole bunch of scan results at once. And then you came up with
this scenario:

>1. An evil program opens a file (but doesn't do anything with 
>it.. yet).
>
>2. User accesses a file. Scan result is cached. The (device, 
>inode) pair 
>is used to identify the file.
>
>3. Evil program writes evil code to file (but doesn't close it, just 
>flushes the data).
>
>4. User accesses the file (with a virus) with the same inode number as 
>the file in step 2 had. The scan result will be found in the cache => 
>BOOM, you're infected
>
>The problem here is not Dazuko, but your criteria for your cache. You 
>know that the file is being opened, but you aren't considering its 
>content may be different.

You have raised a valid point. However, even without a cache, there might be
a window of vulnerability:

1. An evil program opens a file. Dazuko intercepts, the file is scanned and
found clean. File is kept open.

2. Another (nice) program opens the file. Dazuko intercepts, the file is
scanned and found clean.

3. Before the nice program begins reading the file, the evil program writes a
virus into the file.

4. Nice program reads the file and gets infected.

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.

The only way to fix this would be to make it impossible for a program to open
a file in write mode if the file is already open in read mode or open it in
read mode if it is already open in write mode. That is, behave like a
read-write lock. But that would break unix file access semantics. You could
not e.g. read /var/log/messages because it is kept open in write mode by
syslogd.

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. I do
not think my cache implementation greatly increases the risk that is already
there.

>I have two reasons why I would not like this to be in Dazuko right now:
>
>1. I do not believe that implementing this will solve your problem.

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.

>2. The upcoming 2.2.x series of Dazuko is based on a stackable 
>filesystem. I am not sure how well I would be able to support 
>mount/unmount events with such an architecture. I don't want to 
>introduce events into the official API that will be dead in 6 
>months. (I 
>already have enough regrets because of the ON_CLOSE_MODIFIED event.)

Of course, you will develop dazuko in the direction of your choosing with the
pace that suits you. I, however, have to provide a mostly working, if not
100% correct solution to our customers.

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.

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

I will have to think about this.

Actually, there is a third option:

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.

-- 
Sami Tikka                tel. +358 9 2520 5115 
senior software engineer  fax. +358 9 2520 5014
                          mobile +358 40 7379388
F-Secure Corporation      http://www.f-secure.com
BE SURE