DazukoFS: a stackable filesystem for virus scanning

A longstanding out-of-tree kernel feature—used by half-a-dozen or more virus scanners—Dazuko has recently changed its modus operandi in an effort to be included into the mainline. Dazuko, and now DazukoFS, are mechanisms to control access to files, which are generally used to stop Windows viruses from propagating on Linux servers. The goal is similar in many ways to that of fsnotify/fanotify/TALPA, but the DazukoFS implementation as a stackable filesystem is a completely different approach.

The Dazuko project started almost exactly seven years ago as an effort to allow user-space programs—Windows-style anti-virus scanners mostly—to make file access decisions. One of the reasons to have the scanning in user space—aside from the zero probability of getting one added to the kernel—is to keep it vendor-neutral by not favoring any particular anti-virus engine. But the means to that end was system call hooking, which is a technique that is seriously frowned upon by kernel hackers. Dazuko made an abortive move to the LSM API, but ran into various problems, including the inability to stack multiple security modules. Eventually, the project started looking at a stackable filesystem as a solution that would be palatable for moving into the mainline.

Originally suggested for Dazuko by Christoph Hellwig in 2004, a stackable filesystem has a number of advantages over the other solutions. It is a self-contained solution that won't require core kernel code changes if anti-virus developers wish to add new features. It also would add another stackable filesystem to the kernel, which may help foster a more general stackable filesystem framework. But the main reason is that the project sees it as the most likely path into the mainline. Main developer John Ogness explains:

DazukoFS is mounted atop an already-mounted filesystem in order to handle file access decisions for files in the underlying filesystem. For example:

    mount -t dazukofs /opt /opt 

File access decisions are made by processes or threads which make up a "group". Groups act as a pool of available scanners to allow multiple outstanding file access decisions. Once the pool is fully occupied, file accesses will block until one becomes available. Groups are registered by writing "add=MyGroupName" to /dev/dazukofs.ctrl. A group id will then be assigned, which can be parsed from the output of reading the dazukofs.ctrl file. Group ids are then used to access the proper device for providing access decisions.

Based on the group id (N), a /dev/dazukofs.N file is created. Each process in the group registers itself by opening that device. It should then block in a read of the device waiting for a file access event. Each event has three pieces of information that are read from the device file: an event id, the process id of the accessing program, and the number of an open file descriptor that can be used to read the contents of the file. The scanning process should then perform whatever actions it requires to make the decision whether to allow or deny the access.

Because it gets passed an open file descriptor, the scanning process does not need any special privileges beyond those required to access the /dev/dazukofs* files. Once it has made the decision, the scanning process writes a string indicating the result to the device. It is then responsible for closing the file descriptor for the accessed file.

There are a few additional things that can be done via the user-space API: deleting groups, providing for some crash protection within groups, and handling accesses to protected files from within DazukoFS, all of which are described in the Documentation file.

There is also a major caveat that goes with this release of DazukoFS:

That is done, at least partially, to avoid race conditions where a malicious program overwrites the file contents between the scanning and the actual access. This is a general achilles' heel for virus scanning mechanisms, but silently ignoring writes to mapped files is a rather extreme reaction to that problem. TALPA, which has subsequently become fanotify, defines this problem away as not being a part of the threat model it is handling. Perhaps DazukoFS should do something similar.

It would seem likely that only one of the two proposed solutions for user-space file scanning will end up in the mainline. Ogness mentions fanotify in his patch submission:

So far, there has been no comment on the v2 patch submission, but there were some suggestions to the first submission back in December. The kernel filesystem hackers are pretty busy folks in general, but right now there are numerous filesystems in various states of review: btrfs, POHMELFS, DST, FS-Cache, and others. Those may be using up all of the available review bandwidth. Ogness recently announced that he will be dropping support for the 2.x version of Dazuko—based on system call hooks—to focus on DazukoFS. In it he notes the lack of review:

From the announcement, it seems clear that Ogness has the patience necessary to shepherd DazukoFS through the kernel inclusion process. It would seem that spending some time working with Eric Paris to try to find some common ground between their two solutions might be time well spent as well.