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.
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.
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.
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.
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 /.
or configure allowed NetBoot sources, using csrutil netboot.
which clears the existing configuration.
--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.
Posted in Macs, Technology and tagged csrutil, debug, DTrace, El Capitan, extensions, KEXT, NVRAM, OS X 10.11, permissions, rootless, security, SIP. Bookmark the permalink.