1lfCtJ9

2014.4 Security: A Case Study with File System DriversWhat happens in userspace stays in userspace!– Tod McQuillinAs we mentioned in Chapter 1, in a general purpose OS drivers for disk-based filesystems are written assuming that file system images contain trusted input. Whilethis assumption was true long ago, in the age of USB sticks and DVDs it no longerholds. Still, users mount untrusted file systems using kernel code. Arbitrary memoryaccess is known to be possible via the use of a suitable crafted file system image andfixing each file system driver to be bullet-proof is at best extremely hard [115].When run in a rump kernel, a file system driver dealing with an untrusted imageis isolated in its own domain thus mitigating an attack. The rump kernel canthen be attached to the host file system namespace by mounting it, as describedin Section 3.11. This separation mitigates the possibility of a direct memory accessattack on the kernel, but is transparent to users.To give an example of a useful scenario, a mailing list posting described a problemwith mounting a FAT file system from a USB stick causing a kernel crash and completesystem failure. By using a rump kernel with microkernel clients, the problemis only an application core dump. Figure 4.6 illustrates what happens when the filesystem is mounted with the driver running in a rump kernel. Of course, the driverwas fixed to deal graciously with this particular bug, but others remain.It should be stressed that mounting a file system as a server is feature wise nodifferent than using a driver running in the host kernel. The user and administratorexperience remains the same, and so does the functionality. Only the extra layerof security is added. It is the author’s opinion and recommendation that untrusted