A few concerns about fanotify implementation.

* A few concerns about fanotify implementation.
@ 2010-10-26 12:13 Vasily Novikov
  2010-10-26 12:58 ` [malware-list] " Tvrtko Ursulin
  0 siblings, 1 reply; 17+ messages in thread
From: Vasily Novikov @ 2010-10-26 12:13 UTC (permalink / raw)
  To: eparis-H+wXaHxf7aLQT0dZR+AlfA
  Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Novikov, Vasily,
	malware-list-h+Im9A44IAFcMpApZELgcQ

Hi Eric,

We are interested in using fanotify in anti-malware applications. I
found a few concerns in fanotify implementation from the recently
released 2.6.36 kernel:

1. Race in cache implementation.

The cache is implemented as inode ignored mark. I suppose there could be
a race here.
Consider the following scenario with hostile processes A and B, and
victim process C:
1. Process A opens new file for writing. File check request is
generated.
2. File check is performed in userspace. Check result is "file has no
malware".
3. The "permit" response is delivered to kernel space.
4. File ignored mark set.
5. Process A writes dummy bytes to the file. File ignored flags are
cleared.
6. Process B opens the same file for reading. File check request is
generated.
7. File check is performed in userspace. Check result is "file has no
malware".
8. Process A writes malware bytes to the file. There is no cached
response yet.
9. The "permit" response is delivered to kernel space and is cached in
fanotify.
10. File ignored mark set.
11. Now any process C will be permitted to open the malware file.
There is a race between steps 8 and 10.

The race could be easily reproduced by Andreas's fanotify example:
  console1# ./fanotify -s1 -o open_perm,modify,close -m /mnt
  console2# while :; do echo 123 >> /mnt/123.txt; done
echo command opens, then writes, so write should clean ignore mask and
every open call should be intercepted but actually only every 2-nd call
is intercepted.

I be believe it could be solved by introducing two more ignore mark
flags. The fist one to set before the scan starts. It could be cleaned
by write operation. The second one to ask fanotify to set ignore flags
only if the first flag is still set. In this case we will never have
file with not scanned file changes in cache.

2. As I understood it was intended to flush cache via FAN_MARK_FLUSH
flag but it is currently disabled and there is no notion about it in the
man page. There are cases when it is necessary to flush all cache, for
example on anti-malware bases update.

3. I read the discussion about how to define paths to scan but anyway.
We would prefer to have global listener that was defined in the first
version of the interface and mark unnecessary mount points with
persistent ignore flags.

4. FAN_DENY response has no effect at the moment.

Regards,
  Vasily

^ permalink raw reply	[flat|nested] 17+ messages in thread