Cómo identificar las extensiones bloqueadas por Gatekeeper

Lo descifré. En Información del Sistema > Software > Software deshabilitado, se muestra una lista de estas extensiones con su identificador de paquete. En mi caso, esa fue suficiente información para entender de qué se trata la aplicación, pero localizar el archivo kext real requiere más investigación. Ejemplo:

grep -r "com.aladdin.kext.aksfridge" /Library/Extensions no encuentra nada.

grep -r "com.aladdin.kext.aksfridge" /Library/Application Support lo encontró.

No estoy seguro de si hay una lista documentada de ubicaciones permitidas para cargar kexts, pero podrías hacer grep en todo el disco duro para el identificador de paquete y seguramente lo encontrarías.

Prepárate para esperar mientras grep -r busca en todo tu disco duro...

Si encuentras que tu archivo es una extensión ubicada en: /Library/StagedExtensions/Library/Extensions/

sudo rm -rf no funcionará, solo puedes eliminarlo utilizando:

sudo kextcache --clear-staging

Tuve una experiencia similar hoy. Pensé que podría ser útil para ti.

La pestaña "Preferencias del Sistema > Seguridad y Privacidad > General" me mostró un software del sistema bloqueado. Mencionaba al desarrollador 'Jongwoo Choi' que no reconocía. ¿Qué software es este? ¿Dónde está instalado? Después de buscar en internet sobre estas extensiones de software bloqueadas, parecen ser "extensiones del núcleo" o archivos .kext.

Un poco más de búsqueda me enseñó esto:

• "Información del Sistema > Software > Extensiones" muestra todas las extensiones instaladas en tu máquina. Dale algo de tiempo para cargar, la lista puede ser larga.
• Ahora, para encontrar la extensión bloqueada de este desarrollador, ordené la lista por "Obtenido de". Si tienes un nombre de extensión, puedes ordenar por la columna "Nombre de la extensión". La mayoría de las extensiones son obtenidas de Apple, así que supongo que esas puedes omitirlas. También aquellas con el valor "Sí" en "Cargado" pueden ser omitidas ya que el software está bloqueado para cargar. Luego revisé cada ítem de "Desarrollador identificado" o "No firmado".
• Ahora deberías ser capaz de encontrar el nombre del desarrollador o compañía (que fue mencionado en la lista de software bloqueado de la pestaña "Preferencias del Sistema > Seguridad y Privacidad > General") en los detalles que obtienes para cada ítem en la ventana debajo de la lista de extensiones. Revisa el valor de "Firmado por". Para mí solo había una entrada para ese desarrollador específico.
• Una vez que lo encuentres, el valor de "Ubicación" te mostrará donde está localizado el archivo .kext. El valor de "Identificador de paquete" también puede ayudar a explicar de qué se trata.

Dado que las extensiones del núcleo no se cargaron, decidí eliminarla.

sudo rm -rf ruta/al/archivo/.kext

Luego reinicié (no estoy seguro si es necesario). "Preferencias del Sistema > Seguridad y Privacidad > General" no me mostró el mensaje de software bloqueado. ¡Hurra!

Sin embargo, "Información del Sistema > Software > Software desactivado" TODAVÍA me mostró una entrada de software desactivado. Reconocí el título de la entrada por la información detallada en la lista de extensiones anteriormente. Es la que acabo de eliminar. Para mí era "F3YNT8UCP3 - net.sf.tuntaposx.tap"

¿Por qué sigue ahí si eliminé el archivo .kext? Como mencionó Elliott en un comentario arriba, parece que hay una base de datos SQLite que registra información sobre la aprobación del software instalado. Eliminar el archivo .kext no elimina la entrada de la base de datos.

Cómo eliminar la entrada de la base de datos para eliminarla de la lista "Información del Sistema > Software > Software desactivado" se describe en aquí en Stack Overflow. La primera parte de la entrada de software desactivado es el ID del equipo (F3YNT8UCP3 en mi caso). Necesitarás este ID para especificar qué entrada eliminar de la base de datos SQLite.

Entonces, eliminar el archivo .kext debería eliminar la advertencia en "Preferencias del Sistema > Seguridad y Privacidad > General". Eliminar el ítem de la base de datos SQLite debería eliminar la entrada de software desactivado en "Información del Sistema > Software > Software desactivado".

Agregando a tu propia respuesta, Elliott, entonces puedes alimentar este ID de paquete a kextutil:

sudo kextutil -b "com.hp.kext.hp-fax-io"

Lo que te dirá todo lo que siempre quisiste saber al respecto, incluida la ubicación del archivo .kext:

file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/ está en la lista de excepciones de hash, permitiendo cargar
Kext rechazado debido a la política del sistema:  { URL = "file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/", ID = "com.hp.kext.hp-fax-io" }
Fallo en la firma de código: no firmado
Advertencias:
    La identificación de la personalidad CFBundleIdentifier difiere de la kext contenedora (no necesariamente un error, pero raramente hecho):
        HPF00072 FAX - 2
        HPF00006 FAX - 2
[...]

También parece que generalmente puedes encontrar todas esas extensiones en ese directorio:

$ ls -la /Library/StagedExtensions/System/Library/Extensions
drwxr-xr-x@ - root 14 Feb  2013 hp_fax_io.kext
drwxr-xr-x@ - root 19 Aug  2013 hp_Inkjet1_io_enabler.kext
drwxr-xr-x@ - root 19 Aug  2013 hp_Inkjet9_io_enabler.kext
drwxr-xr-x@ - root 31 Okt  2014 intelhaxm.kext
drwxr-xr-x@ - root 22 Mai  2012 JMicronATA.kext
drwxr-xr-x@ - root 16 Aug  2012 Pen Tablet.kext
drwxr-xr-x@ - root 23 Jul  2016 SiLabsUSBDriver64.kext
drwxr-xr-x@ - root 23 Jul  2016 Wacom Tablet.kext

Vine a esta discusión mientras intentaba validar kexts migrados de 10.13 a 10.15 que no se estaban cargando. Parece que he encontrado una explicación y una solución alternativa.

Los kexts eran válidos para 10.15 pero no se habían instalado bajo 10.15, ya que llegaron con una migración de sistema. Supongo que el mismo problema ocurriría con una actualización del sistema operativo. (No hace falta decir que estoy profundamente decepcionado con Apple por no prever esta eventualidad)

Encontré el siguiente consejo sobre cómo instalar controladores SATSMART en las preguntas frecuentes en binaryfruit.com que tiene cierta relevancia para la pregunta:

Cómo reconstruir la caché de extensiones/controladores del kernel de macOS

Cuando macOS arranca – guarda todas las extensiones de kernel (controladores) actualmente usadas en una caché para un arranque más rápido la próxima vez – y si mueves cosas en "/Library/Extensions/" y "/System/Library/Extensions/" – no verás esos cambios reflejados hasta que las cachés se reconstruyan. Además, debido a errores en algunas versiones de macOS – la caché de kexts se vuelve obsoleta o se corrompe, especialmente en el caso de actualizaciones del sistema. Reconstruir manualmente la caché de kexts podría solucionar muchos problemas con los controladores (extensiones del kernel).

Escribe en la terminal los siguientes comandos:

sudo kextcache -i /

sudo kextcache -system-caches

El primer comando muestra una lista completa de kexts que no se estaban cargando por diversas razones - incluyendo (pero no limitándose a) Kext rechazado debido a la política del sistema lo que significa que no se había concedido permiso en Seguridad y Privacidad - junto con sus ubicaciones.

En mi experiencia, los kexts bloqueados por razones distintas a necesitar aprobación del usuario aparecen aquí, incluso si no aparecen entre el Software Deshabilitado.

Abordando la pregunta original de los OPs de manera más específica sobre cómo saber quiénes son los desarrolladores de los kexts, dado que esto puede no corresponder directamente con la marca del software, estos pueden ser analizados mediante aplicaciones de inspectores de paquetes como Pacifist y luego comparados con los nombres de los kexts generados por el comando de terminal mencionado anteriormente.

Mi preferencia personal es abrir un paquete de instalación en Suspicious Package, donde el desarrollador y su TeamID alfanumérico de 10 caracteres son fácilmente legibles. Para los kexts que simplemente esperan la aprobación del usuario, esto, por supuesto, corresponde con el TeamID encontrado en el Software Deshabilitado, como explicó el OP anteriormente. Sin embargo, no solo es amigable para el usuario, también expone los kexts que no se cargarán por otras razones.

Una vez que se conoce el TeamID, el kext puede ser aprobado de forma segura en Seguridad y Privacidad cuando aparezca la alerta de kext bloqueado la próxima vez (por ejemplo, al instalar un kext diferente).

No todo el mundo quiere instalar un nuevo kext para aprobar los anteriores y algunas fuentes (como esta base de conocimiento MIT) aconsejan que se pueda otorgar aprobación de kext a través de comandos de terminal en Modo de Recuperación, pero yo personalmente no puedo verificar si esto funciona en un OS específico.

No tengo una respuesta completa, pero hay esfuerzos asombrosos de ingeniería inversa y intercambio de información que podrían proporcionarte la pieza final o un punto de partida suficiente para construir el tuyo propio.

Richard Purves ha realizado un trabajo asombroso para cubrir la "kextpocalipsis" y el scripting, y la mayoría de los principales proveedores de MDM tienen ejemplos específicos de cómo empujar listas blancas y lidiar con estas extensiones de kernel aprobadas por el usuario.

Además, ten en cuenta que el comportamiento no está completamente definido, ya que Apple está refinando y cambiando la forma en que esto funciona en cada versión (últimamente), así que tu experiencia puede variar más de lo habitual.

• https://www.richard-purves.com/2017/11/12/kextpocalyse-2-the-remediation/

Michael Lynn también va mucho más allá de lo que esperaría de un consultor pagado, publicando scripts potentes y documentándolos de manera experta.

• Consultando directamente el estado activo de SIP desde el kernel, pasando por alto nvram y csrutil, a través de Python en macOS