Cómo identificar extensiones bloqueadas por Gatekeeper

Me lo imaginé. En Información del sistema > Software > Software deshabilitado, muestra una lista de estas extensiones con su identificador de paquete. En mi caso, esa fue suficiente información para comprender qué es la aplicación, pero para ubicar el archivo kext real se requiere más investigación. Ejemplo:

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

grep -r "com.aladdin.kext.aksfridge" /Library/Application SupportLo encontré.

No estoy seguro de si hay una lista documentada de ubicaciones que pueden cargar kexts, pero podría buscar el ID del paquete en todo el disco duro y eso seguramente lo encontraría.

Yo tuve una experiencia similar hoy. Pensé que podría ser de ayuda para ti.

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

Algunas búsquedas más me enseñaron esto:

• "Información del sistema > Software > Extensiones" muestra todas las extensiones instaladas en su máquina. Dale un poco de tiempo para cargar, la lista puede ser larga.
• Ahora, también busque la extensión bloqueada por este desarrollador, ordené la lista por "Obtenida de". Si tiene un nombre de extensión, puede ordenar por columna "Nombre de extensión". La mayoría de las extensiones se obtienen de Apple, así que supongo que se pueden omitir. También aquellos con el valor "Cargado" "sí" también se pueden omitir ya que el software está bloqueado para que no se cargue. Luego revisé cada elemento de "Desarrollador identificado" o "No firmado".
• Ahora debería poder encontrar el nombre del desarrollador o de la empresa (mencionado en la lista de la pestaña "Preferencias del sistema > Seguridad y privacidad > General" del software bloqueado) en los detalles que obtiene para cada elemento en la ventana debajo de la lista de extensiones. Compruebe el valor de "Firmado por". Para mí, solo había una entrada para ese desarrollador específico.
• Una vez que lo haya encontrado, el valor de "Ubicación" le mostrará dónde se encuentra el archivo .kext. El valor de "ID de paquete" también podría ayudar a explicar de qué se trata.

Como las extensiones del kernel no estaban cargadas, decidí eliminarlas.

sudo rm -rf path/to/the/kext/file

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 deshabilitado" todavía me mostró una entrada de software deshabilitado. Reconocí el título de la entrada de la información detallada en la lista de extensiones anterior. Es el que acabo de quitar. Para mí esto fue "F3YNT8UCP3 - net.sf.tuntaposx.tap"

¿Por qué sigue ahí mientras eliminé el archivo .kext? Como mencionó Elliott en un comentario anterior, parece que hay una base de datos SQLite que rastrea 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 deshabilitado" se describe aquí en Desbordamiento de pila . La primera parte de la entrada del software deshabilitado es el ID del equipo (F3YNT8UCP3 en mi caso). Necesitará este ID para especificar qué entrada eliminar de la base de datos SQLite.

Por lo tanto, eliminar el archivo .kext debería eliminar la advertencia en "Preferencias del sistema> Seguridad y privacidad> General". Eliminar el elemento de la base de datos SQLite debería eliminar la entrada de software deshabilitado en "Información del sistema> Software> Software deshabilitado".

Agregando a su propia respuesta, Elliott, puede enviar este ID de paquete a kextutil:

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

Que luego le dirá todo lo que siempre quiso saber al respecto, incluida la ubicación del .kextarchivo:

file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/ is in hash exception list, allowing to load
Kext rejected due to system policy: <OSKext 0x7fe302c19730 [0x7fffa5fc38f0]> { URL = "file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/", ID = "com.hp.kext.hp-fax-io" }
Code Signing Failure: not code signed
Warnings:
    Personality CFBundleIdentifier differs from containing kext's (not necessarily a mistake, but rarely done):
        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

No tengo una respuesta completa, pero hay increíbles esfuerzos de ingeniería inversa e intercambio de información que podrían brindarle la pieza final o un punto de apoyo suficiente para rodar el suyo.

Richard Purves ha realizado un trabajo increíble para cubrir "kextpocalypse" y secuencias de comandos, y la mayoría de los principales proveedores de MDM tienen ejemplos específicos de cómo impulsar listas blancas y lidiar con estas extensiones de kernel aprobadas por el usuario.

Además, tenga en cuenta que el comportamiento no está completamente configurado ya que Apple está perfeccionando y cambiando la forma en que funciona en cada versión (últimamente), por lo que YMMV es más de lo habitual.

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

Michael Lynn también está mucho más allá de lo que esperaría de un consultor pagado que produce guiones poderosos y los documenta de manera experta.

• Consultar el estado de SIP activo directamente desde el kernel, sin pasar por nvram y csrutil, a través de python en macOS

Llegué 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.

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

Encontré los siguientes consejos sobre la instalación de controladores SATSMART en las preguntas frecuentes en binaryfruit.com , que tienen cierta relevancia para la pregunta:

Cómo reconstruir extensiones de kernel de macOS/caché de controlador

Cuando macOS arranca, guarda todas las extensiones de kernel (controladores) utilizadas actualmente en una memoria caché para un arranque más rápido la próxima vez, y si mueve las cosas en "/Library/Extensions/" y "/System/Library/Extensions/", usted no verá esos cambios reflejados hasta que se reconstruyan los cachés. Además, debido a errores en algunas versiones de macOS, la caché de kext se vuelve obsoleta o se corrompe, especialmente en el caso de actualizaciones del sistema. La reconstrucción manual de caché de kext 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 varios motivos, incluido (entre otros) Kext rechazado debido a la política del sistema, lo que significa que no se había otorgado permiso en Seguridad y privacidad, junto con sus ubicaciones.

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

Abordando la pregunta original de los OP más específicamente con respecto a saber quiénes son los desarrolladores de kext, ya que esto puede no corresponder directamente a la marca del software, estos pueden analizarse desde aplicaciones de inspección de paquetes como Pacifist y luego compararse con los nombres de kext generados por el comando de terminal anterior .

Mi preferencia personal es abrir un paquete de instalación en Paquete sospechoso , 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 se corresponde, por supuesto, con el TeamID que se encuentra en el software deshabilitado, como se explica en el OP anterior. Sin embargo, no solo es fácil de usar, sino que también expone kexts que no se cargarán por otras razones.

Una vez que se conoce el TeamID, el kext se puede aprobar de forma segura en Seguridad y privacidad cuando se muestra la alerta de kext bloqueado (por ejemplo, al instalar un kext diferente).

No todos quieren instalar un nuevo kext para aprobar los anteriores y algunas fuentes ( como esta base de conocimiento del MIT ) advierten que se puede otorgar la aprobación de kext a una ID de equipo a través de comandos de terminal en modo de recuperación, pero no puedo verificar personalmente si esto funciona en un sistema operativo específico.