macOS 10.13 High Sierra: a fondo con la carga de las extensiones de kernel

Qué es una extensión de kernel

OS X primero y luego macOS proporcionan un mecanismo de extensión del kernel como medio para permitir la carga dinámica del código en el kernel, sin necesidad de recompilar o reenlazar. Debido a que estas extensiones del núcleo (KEXTs) proporcionan tanto modularidad como capacidad de carga dinámica, son una opción natural para cualquier servicio relativamente autónomo que requiera acceso a interfaces internas del kernel.

Debido a que los KEXTs se ejecutan en modo supervisor en el espacio de direcciones del kernel, también son más difíciles de escribir y depurar que los módulos de nivel de usuario y deben cumplir con pautas estrictas. Además, los recursos del kernel están wired (residentes permanentes en la memoria) y por lo tanto son más costosos de usar que los recursos en una tarea de espacio de usuario de funcionalidad equivalente.

Además, aunque la protección de memoria evita que las aplicaciones bloqueen el sistema, no existen tales protecciones dentro del núcleo. Una extensión de kernel con un mal comportamiento en OS X/macOS puede causar tantos problemas como una aplicación o extensión con un mal comportamiento en, por ejemplo, en la anterior generación de sistemas operativos, concretamente en Mac OS 9, que se bloqueaba totalmente cuando ocurría un problema de este tipo.

Los errores en KEXTs pueden tener consecuencias mucho más graves que los fallos en el código de usuario. Por ejemplo, un error de acceso a la memoria en una aplicación de usuario puede, en el peor de los casos, causar que esa aplicación se bloquee. Por el contrario, un error de acceso a la memoria en un KEXT provoca un pánico en el kernel, provocando un fallo en el sistema operativo.

Por último, por razones de seguridad, algunos clientes restringen o no permiten el uso de KEXTs de terceros. Como resultado, se desaconseja encarecidamente el uso de KEXTs en situaciones donde las soluciones a nivel de usuario son factibles. OS X garantiza que el threading en aplicaciones es tan eficiente como el threading dentro del núcleo, por lo que la eficiencia no debería ser un problema. A menos que una aplicación requiera un acceso de bajo nivel a las interfaces del kernel, debería utilizar un nivel más alto de abstracción cuando desarrolle código para OS X/macOS. Cuando un desarrollador está tratando de determinar si una pieza de código debe ser un KEXT, la respuesta por defecto es generalmente no.[note]Documentación para desarrolladores de Apple[/note]

¿Por qué se siguen utilizando extensiones de kernel entonces?

En la mayoría de los casos estas extensiones de kernel se utilizan cuando una aplicación requiere de acceso a un nivel profundo del sistema en la mayoría de las ocasiones porque ese acceso es necesario para trabajar con un periférico externo, independientemente del tipo que sea. Cuanto más especializado sea ese periférico y menos estándares cumpla, más necesario será el uso de una Kext para hacerlo funcionar correctamente en el Mac.

Precisamente por este tipo de circunstancias, Apple hace muchos años que empezó a adherirse a ciertos estándares a la hora de trabajar con periféricos por dos razones:

• Permitir que muchos periféricos funcionaran con el Mac directamente, ampliando la disponibilidad de dispositivos para los usuarios
• Eliminar la necesidad de que el fabricante tuviera que desarrollar drivers personalizados que incluyeran en muchos casos, extensiones de kernel que pudieran causar problemas al sistema[note]kernel panics, consumo elevado de recursos, etc…[/note]

Los más viejos del lugar recordarán que en un momento determinado de Mac OS X, cualquier dispositivo USB genérico de la clase II empezaba a funcionar en el Mac sin la necesidad de drivers[note]Lo que supuso, por ejemplo, que un buen número de webcams solo para PC funcionaran automágicamente de una versión a otra del sistema sin la necesidad de drivers[/note]: la adopción de esos estándares benefició al usuario en muchos sentidos y de paso hizo mucho más fácil la vida de Apple.

Las extensiones de kernel también se utilizan, a nivel de software, para dar acceso de forma amplia al sistema a estándares que no están soportados pero que no están relacionados directamente con un hardware específico. Por ejemplo, si alguien quisiera crear un Driver de compatibilidad para APFS para OS X 10.11 El Capitan, pro ejemplo, de forma que el sistema y aplicaciones de terceros pudieran acceder, leer y escribir archivos en un disco formateado en este sistema de archivos, debería utilizar una extensión de kernel.

Lo mismo ocurre, por ejemplo, con los drivers de una impresora o el acceso a un sistema de copias de seguridad basado en cinta. La premisa es sencilla: si el servicio o aplicación va a ser usado de forma general era todo el sistema por todo tipo de aplicaciones, hay que escalar hacia arriba hacia el kernel de forma que cualquier otra aplicación pueda acceder al servicio[note]Por ejemplo, imprimir, acceder a un servicio de almacenamiento especializado[/note] de forma natural, sin la necesidad de modificar la aplicación para que entienda este nuevo servicio implementado en el sistema. Si echas un vistazo, por ejemplo, a /Library/Extensions te encontrarás allí diferentes extensiones de kernel, algunas de ellas instaladas por aplicaciones que requieren este tipo de acceso y cuyo nombre resulta fácilmente identificable[note]Otras, no tanto[/note].

De hecho, como normal y en general, las aplicaciones genéricas que no ofrezcan servicios de amplio aspecto al sistema o requieran de acceso a periféricos no deberían instalar extensiones de kernel: es más, resulta como poco, sospechoso.

macOS 10.13 High Sierra y las extensiones de kernel

Las extensiones de kernel son, sin embargo, un problema de seguridad como tal. Una vez instaladas, tienen acceso al kernel del sistema y ya puedes imaginar que cuanto más adentro, más daño. Para evitar este problema de seguridad, de la misma forma que el usuario debe aceptar la ejecución de una aplicación por primera vez, incluso si ésta está firmada por un desarrollador pero no se ha descargado desde la Mac App Store, lo mismo ocurre con las extensiones de kernel: con macOS 10.13 High Sierra el usuario debe aprobarlas manualmente. Así el usuario tiene la información necesaria a la hora de instalar una aplicación que carga adicionalmente extensiones de kernel, ya que le aparecerá un cuadro de diálogo indicándole que se ha bloqueado una extensión de kernel en la instalación / ejecución de una aplicación y que manualmente debe darle paso. Esto ocurre incluso cuando la extensión de kernel está firmada por un desarrollador[note]En versiones anteriores a macOS 10.13 High Sierra, con que la extensión de kernel estuviera firmada por un desarrollador era más que suficiente para darle paso, pero ya no más.[/note]. Las extensiones de kernel heredadas de versiones anteriores del sistema, cuando has hecho una actualización, se aprueban automáticamente después del proceso de actualización del sistema.

Aprobando extensiones

Esta característica de macOS 10.13 High Sierra garantiza que sólo las extensiones del kernel aprobadas por el usuario se cargarán en el sistema. Cuando se hace una petición para cargar una extensión de Kernel[note]KEXT[/note] que el usuario no ha aprobado todavía, la petición de carga es negada y macOS presenta un cuadro de alerta que le pide al usuario que apruebe el KEXT en Preferencias del sistema > Seguridad y privacidad.

Esta interfaz de usuario de aprobación sólo está presente en el panel Preferencias de seguridad y privacidad durante 30 minutos después de la alerta. Hasta que el usuario apruebe la extensión de kernel, los intentos de carga futuros causarán que la interfaz de usuario de aprobación vuelva a aparecer pero no se activará otra alerta de usuario.

La alerta muestra el nombre del desarrollador que ha firmado la extensión de kernel para que el usuario pueda decidir si aprueba o no la extensión de kernel. Este nombre proviene del campo Subject Common Name del certificado de aplicación de ID de desarrollador utilizado para firmar la extensión de kernel. Debido a esto, se recomienda a los desarrolladores que proporcionen un nombre de empresa apropiado cuando soliciten identidades de firma de la extensión de kernel.

Cuando el usuario aprueba una extensión de kernel, está al mismo tiempo aprobando todas las extensiones de kernel firmadas por el mismo Team ID en lugar de tener que aprobarlas una a una. Si la extensión de kernel aprobado se encuentra en el paquete de una aplicación, también se aprueban todas las demás extensiones de kernel firmadas por el mismo ID de equipo en el paquete de la misma aplicación. Si la extensión de kernel aprobada se encuentra en el subdirectorio de la aplicación dentro de /Library/Application Support, todos las demás extensiones de kernel firmadas por el mismo ID de equipo que se encuentra en ese mismo subdirectorio también están aprobadas. Todos las extensiones de kernel en /Library/Extensions firmadas por el mismo ID de equipo también están aprobadas.

Una vez aprobada, la extensión de kernel se cargará o añadirá inmediatamente a la caché del núcleo enlazado previamente, dependiendo de la acción bloqueada. Las solicitudes posteriores para cargar la extensión de kernel procederán silenciosamente como en las versiones anteriores de macOS.

Las extensiones de kernel aprobadas se almacenan y rastrean en una base de datos de políticas a nivel de todo el sistema a través del identificador de equipo en la firma de código de la extensión de kernel y el identificador de paquete de la lista Info.plist[note]A estas alturas, es interesante comentar que una extensión de kernel no es un archivo, sino un grupo de archivos empaquetados en un bundle por lo que se puede hacer clic con el botón alternativo del ratón para mirar en su interior[/note] de la extensión de kernel, por lo que la actualización de una extensión de kernel ya aprobado no desencadenará una nueva solicitud de aprobación.

Inspeccionando una extensión de kernel

Cuando echas un vistazo a las ubicaciones en las que se guardan extensiones de kernel te puedes encontrar con nombres que no ayudan mucho: por ejemplo, DuetDisplay.kext te deja bastante claro a que aplicación corresponde la extensión, pero por ejemplo ACS6x.kext no tanto. ¿Cómo podemos investigar una extensión?:

• Haz clic con el botón alternativo del ratón en la extensión y elige en el menú contextual mostrar contenido del paquete
• Abre el archivo info.plist[note]No modifiques nada, que la rompes[/note]
• Busca en el XML las etiquetas CFBundleGetInfoString y CFBundleIdentifier
• En el caso de ACS6x.kext, CFBundleGetInfoString indica que la extensión de kernel corresponde a una empresa que se llama Accusys.

Al hacer una búsqueda de esta empresa en internet, aprendemos que: Accusys Storage Ltd. is a leading innovator of high-performance storage solutions designed for entertainment media and post production markets. Accusys specializes in providing the latest in scalable SAN storage, Thunderbolt share storage and PCIe storage solutions for digital content creation professionals. Así que ya nos podemos hacer una idea para qué se utiliza esa extensión de kernel: ofrece servicios de acceso como driver a sistemas de almacenamiento o dispositivos profesionales, posiblemente de terceras partes.

Si seguimos investigando el archivo vemos más abajo que al respecto de las Características del Protocolo en el XML se cita específicamente Fibre Channel Interface por lo que ya sabemos para que sirve: para integrar una tarjeta de este tipo en el sistema.

En general, no vamos a tener que jugar con las extensiones de kernel ni preocuparnos excesivamente de ellas en nuestro día a día, pero sí es conveniente saber cómo funciona todo este entramado. Todas estas medidas de seguridad implementadas por Apple, incluyendo la decisión de ejecución por parte del usuario están diseñadas para ofrecer una barrera más para el malware. Hacer más complicada la carga de una extensión maliciosa, incluso cuando ésta puede estar firmada evita que a un nivel profundo y primario del sistema una aplicación maliciosa pueda hacer destrozos de todo tipo.