Professional Cocoa® Application Security

Chapter 11. Kernel Extensions

WHAT'S IN THIS CHAPTER?

• The kernel's security environment

• Vetoing filesystem access

Writing kernel extensions, or KEXTs, is a very different matter from building user applications. Your kernel extension code receives an unmatched level of access to the operating system's facilities, and a corresponding elevated level of care must be taken to stop that access from being abused.

Warning

Apple's kernel programming guide tells you to keep out of the kernel. This is a good warning, and I want to reinforce it here. Only ship a kernel extension if your product cannot be implemented without it. The restrictions and requirements on kernel code are entirely unlike those on a user application, and there are many pitfalls that can lead to systems becoming unresponsive with no chance for users to save their data.

For some scenarios in which you might consider developing a KEXT, there are alternatives that allow you to avoid it. If you want to implement a new filesystem, use the MacFUSE library, available at http://code.google.com/p/macfuse/. MacFUSE implements a small, well-tested virtual filesystem KEXT that calls out to user-level applications to read and write data. You write an application that interacts with your filesystem and responds to callbacks from the KEXT — avoiding the need for you to deal directly with kernel development.

If you need to write a device driver, consider using the user-level library provided by Apple, IOKit.framework, to stay out of the kernel. ...