Installing and Loading Kernel Extensions
KEXT bundles will normally be installed in the system directory/System/Library/Extensions. You can keep KEXTs outside of this directory; however, you will then need to take care of loading the KEXT yourself by using the method outlined in the next section. The KEXT will still need to have the correct permissions set. A KEXT needs to be owned by the root user, belong to the wheel group, and have the permissions mask 0755 in order to be loadable by the KEXT daemon (kextd).
For I/O Kit-based drivers, the KEXT is usually loaded automatically by the KEXT daemon when its provider is registered in the I/O Registry (assuming the KEXT has a proper personality defined in its Info.plist file). A KEXT not associated with a hardware provider can load itself automatically at system startup by using the IOResources nub as a provider. For non-I/O Kit based KEXTs, such as NKEs or virtual network drivers, this will not be possible, as IOResources is not available for KEXTs outside the I/O Kit.
For non I/O Kit KEXTs, a Launch Daemon can be created. Launch Daemons and Agents are Apple’s replacements for a number of traditional UNIX services including init.d, cron, and inetd. Agents are run as a user logs into the system based on that user’s security permissions. Daemons, on the other hand, are system–wide and are generally run with root permissions. We can use a Launch Daemon to execute a shell script when the computer starts, which will in turn load our KEXT. To create a launch agent, simply define a plist file as shown in Listing 18-1.
Listing 18-1. Launch Daemon Property List File
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.osxkernel.launchd.HelloWorld</string>
<key>ProgramArguments</key>
<array>
<string>/Library/Application Support/HelloWorld/loadkext.sh</string>
<string>load</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
This file should be installed to /System/Library/LaunchDaemon or ~/Library/LaunchDaemon, as com.osxkernel.launchd.HelloWorld.plist. The Launch Daemon will now trigger the loadkext.sh script during startup. The script itself can be implemented as shown in Listing 18-2.
Listing 18-2. UNIX Shell Script for Loading a KEXT
#!/bin/sh
COMMAND=$1
THEKEXT=/System/Library/Extensions/HelloWorld.kext
if [ -f "$THEKEXT" ]
then
echo "KEXT does not exist"
exit 1
fi
if [ "$COMMAND" = "load" ]
then
kextload $THEKEXT
elif [ "$COMMAND" = "unload" ]
then
kextunload $THEKEXT
fi
In some cases, it may be desirable to load the KEXT on demand, rather than at system boot. For example, in the case of a VPN (Virtual Private Network) application, it may come with a KEXT to handle a custom network level encryption scheme or install a virtual VPN interface. This KEXT is only needed for as long as the application remains active. Having it active wastes memory resources, and loading it at boot may potentially impact startup time. Furthermore, since the KEXT interacts with the network stack, it may actually get in the way and impact the system’s network performance. In this case, the application may wish to load and unload the KEXT dynamically. This can be achieved by using a script like the preceding one. The application would need to run with root privileges in order to load and unload the KEXT. It is not a good idea, however, to make an entire application setuid root, as this can lead to a serious security problem. An alternative solution involves executing a minimal helper program using the AuthorizationExecuteWithPrivileges() API to temporarily escalate the privileges of the executed program. This will prompt the user for the computer’s system password. It is possible to allow a KEXT to be loaded by a non–root user by modifying its plist file to include the following:
<key>OSBundleAllowUserLoad</key>
<true/>
While this will allow a non–privileged process or user to load the KEXT, root privileges are still required to unload the KEXT afterward. As such, the former technique is preferred and is also more secure, as users will have to approve the action explicitly.
KERNEL EXTENSIONS ON THE APP STORE