The previous article looked at the protection provided by El Capitan’s System Integrity Protection (SIP) to files and folders. But there is more: it also limits the kernel extensions (KEXTs) which can be used, and provides some runtime protection too.

KEXTs

Kernel extensions are privileged code modules which work low-down, close to the OS X kernel. They are not only a good means of attack in malware, but buggy extensions can quickly bring your Mac to its knees. For a kernel extension to be loaded, SIP and its related security systems now require that it is signed using a special developer ID for the purpose – a regular signature is not good enough for KEXTs any more – and that it is not on the list of banned KEXTs.

It is still possible to install an unsigned KEXT, but you will have to disable SIP first, and ensure that it is not on the banned list. This is not recommended, of course.

The kernel extension exclude list is kept at /System/Library/Extensions/AppleKextExcludeList.kext, and is one of those which Apple updates silently. When it does so, Installations listed in System Information reports an update to Incompatible Kernel Extension Configuration Data, which is currently at version 3.30.1.

Objective-See also provides a tool for probing your kernel extensions in the free KextViewr.

The most probable ways for malware to try to bypass this protection are:

• exploiting any vulnerabilities which might exist in SIP and security code implementing this,
• social engineering to get you to install it from Recovery mode,
• abuse of a valid security certificate.

For most users, these changes in the loading of kernel extensions should pass unnoticed. However, if you are trying to install or use a product, particularly a peripheral, which relies on extensions to function, they can make the product unusable. All developers who support their products properly should by now have migrated from the use of kernel extensions, or obtained their special developer ID to allow their extensions to be used in El Capitan. There is no excuse for failure.

Runtime protection

To the normal Mac user, these security measures should not be noticed at all, but for a small number they have caused major problems.

Some specialist system calls, task_for_pid() and processor_set_tasks(), now fail; the exec(2) call resets Mach special ports; the dynamic link editor dyld ignores environment variables when launching protected processes; DTrace probes and other means of attaching to system processes are not available; and writing to NVRAM is restricted.

These make it much harder for researchers to examine other people’s code, although developers are still of course able to inspect and debug their own code during development. This has caused a lot of complaints in the research and development communities, but should not affect other users in any significant way.

Controlling SIP

There is no friendly front-end to SIP: without entering Terminal’s command line, it is on, in full, as long as you are running El Capitan. It does, though, only protect your startup volume, which is the current root volume mounted on /.

From the command line, the utility that you need to monitor or control SIP is csrutil, which does not yet have a man page. When running normally, you can only show SIP’s status, using
csrutil status
or configure allowed NetBoot sources, using csrutil netboot.

When started up in Recovery mode, there are three additional commands which become available:
csrutil enable
which enables SIP,
csrutil disable
which disables SIP, and
csrutil clear
which clears the existing configuration.

You can also enable parts of SIP when in Recovery mode: csrutil enable allows the following options:

• --without kext : without Apple internal and KEXT signing protection
• --without fs : without Apple internal and file system protection
• --without debug : without Apple internal and debugging protection
• --without dtrace : without Apple internal and DTrace protection
• --without nvram : without Apple internal and NVRAM protection.

Does SIP make OS X rootless?

In plain Unix, the root user is all-powerful, and that has changed with SIP in El Capitan. However, the root user still exists, and within the limits imposed by SIP is as powerful as it ever was. When you do need to run with root privileges, you can still use sudo, but there are now some things that will not get you past.

So the best answer is that El Capitan is not rootless, and shame on whoever in Apple thought to use that term in SIP’s configuration files. The only way that we will know whether this has all been worthwhile is if it does prevent malware from getting the better of us.

References

StackExchange discussion
Rich Trouton’s account
Apple developer docs.