Wrapfs and the examples we built from it prove that useful, non-trivial, stackable security file systems can be implemented on modern operating systems without having to change the rest of the system. Many practical security features were added using small amounts of code and implemented in less than a day. Better performance and enhanced security was achieved by running the file systems in the kernel instead of at user-level. File systems built from Wrapfs are more portable than other kernel-based file systems because they interact directly with a (mostly) standard vnode interface, as the quick ports to Linux and FreeBSD showed.
Estimating the complexity of software is a difficult task. Kernel development in particular is slow and costly because of the hostile development environment. Furthermore, personal experience of the developers figure heavily in the cost of development and testing of file systems. Nevertheless, it is our assertion that once Wrapfs is ported to a new operating system, other non-trivial file systems built from it can be prototyped in a matter of hours or days. We estimate that Wrapfs can be ported to any operating system in less than one month, as long as it has a Vnode interface that provides a private opaque field for each of the major data structures of the file system. In comparison, traditional file system development often takes many months to several years and requires large teams of programmers.
Wrapfs saves the developers from dealing with kernel internals, and allows them to concentrate on the specifics of the security file system they are developing. We hope that with Wrapfs and the example security file systems we have built, other developers would be able to prototype new file systems to try new security ideas, develop fully working ones, and port them to various operating systems--bringing the complexity of file system development down to the level of common user-level software.
As mentioned in Section 2.1.1, this first implementation of Wrapfs does not support algorithms that change the input size (e.g., compression). We have outlined several possible designs for supporting such algorithms efficiently and plan to implement a few of them to find out which one best balances the added code complexity with performance.
We also plan to port our system to Windows NT. NT has a different file system interface than Unix's vnode interface. NT's I/O subsystem defines its file system interface. NT Filter Drivers are optional software modules that can be inserted above or below existing file systems. Their task is to intercept and possibly extend file system functionality. One example of an NT filter driver is its virus signature detector. It is therefore possible to emulate file system stacking under NT.