6 votos

Cargar una extensión del kernel que no es de confianza en macOS Mojave

El Volta La aplicación está instalada en mi MacBook Pro, con MacOS 10.14 Mojave.

Esta aplicación necesita una extensión del kernel para funcionar correctamente, y dicha extensión no tiene las firmas de código adecuadas. Esto significa que es necesario manipular la protección de integridad del sistema para cargar esta extensión.

En MacOS 10.13 High Sierra, se puede ejecutar csrutil enable --without kext para desactivar parcialmente el SIP (se permite la carga de kexts sin firma, pero se mantienen otras protecciones). Según el informe de Volta instrucciones de instalación En Mojave hay que desactivar totalmente el SIP, dejando todo el ordenador desprotegido por una extensión del kernel.

Como referencia, esta es la salida de kextutil -l aplicada a esta extensión:

$ sudo kextutil -l /Applications/Volta.app/Contents/Resources/Driver.kext
Untrusted kexts are not allowed
Kext with invalid signature (-67050) denied: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext
Bundle (/Applications/Volta.app/Contents/Resources/Driver.kext) failed to validate, deleting: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext
Unable to stage kext (/Applications/Volta.app/Contents/Resources/Driver.kext) to secure location.

Y este es el resultado de ejecutar codesign --display --verbose=4 /Applications/Volta.app/Contents/Resources/Driver.kext como se sugiere en Respuesta de Ricardo Anjos :

Executable=/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver
Identifier=com.gmathews.volta.driver
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=345 flags=0x0(none) hashes=3+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=cbf1caa72d5071c35aa3c020d557a084e6e5a8c9
CandidateCDHash sha256=468cc8b2215b53445cb650c94a76413db62a4815
Hash choices=sha1,sha256
Page size=4096
CDHash=468cc8b2215b53445cb650c94a76413db62a4815
Signature size=4697
Authority=Developer ID Application: Gary Mathews (SFS8238QUB)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=26 Jul 2018 23:14:21
Info.plist entries=19
TeamIdentifier=SFS8238QUB
Sealed Resources version=2 rules=13 files=0
Internal requirements count=1 size=220

Aquí está también la salida para codesign -v en el mismo archivo:

/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: valid on disk
/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: satisfies its Designated Requirement

También seguí el mismo proceso con el ejecutable principal así como con la aplicación de ayuda, y todos se verificaron (firmas válidas, y la misma autoridad e ID de equipo).

He comparado la salida de codesign a otro kext aleatorio de terceros en mi ordenador, que funciona bien sin necesidad de sortear el SIP, y no pude detectar ninguna diferencia.

Además, Página de preguntas frecuentes de Volta instruye al usuario sobre cómo trabajar alrededor de SIP, por lo que parece una decisión deliberada del desarrollador y no sólo un error.

Me molesta mucho esta situación. Como propietario legítimo de esta máquina, y teniendo acceso físico a ella, ¿no hay nada que pueda hacer (aparte de desactivar completamente el SIP) para poner en la lista blanca esta extensión del kernel, suponiendo que el desarrollador no pueda firmar la extensión por alguna razón? No me importa si hay que introducir comandos crípticos en el modo de recuperación, escribir cosas en la NVRAM o firmar el código de la extensión yo mismo, siempre y cuando no tenga que pagar a Apple 99 dólares por el privilegio.

3voto

NightCrawler Puntos 111

He escrito al desarrollador y he recibido la siguiente respuesta (espero que no le importe que la publique aquí):

Preferiría no tener la limitación de desactivar el SIP para instalar el controlador del kernel de Volta. Pero Apple ha rechazado mi solicitud de firmar el controlador (comprensiblemente) ya que hace cambios de bajo nivel en los registros específicos de la máquina de la CPU.

Puedes leer sobre los MSR en la documentación de la arquitectura de Intel (capítulo 35): https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf

¿Por qué es necesario el controlador del núcleo? Para ejecutar las instrucciones WRMSR y RDMSR se necesitan permisos a nivel del núcleo.

Es posible deshabilitar parcialmente el SIP permitiendo únicamente la instalación de controladores del núcleo sin firmar, pero manteniendo otras protecciones del SIP.

Los controladores no firmados solían estar permitidos hasta las últimas versiones de MacOS; siempre que tengas cuidado con lo que instalas en tu Mac deberías estar bien.

Le contesté preguntando si Apple también tenía poder de veto sobre los kexts aunque no se distribuyeran en la App Store. Su respuesta:

Correcto, independientemente del método de distribución.

https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html

"Puede solicitar un certificado de ID de desarrollador para firmar kexts visitando https://developer.apple.com/contact/kext y rellenar los datos requeridos".

Mi solicitud fue rechazada, incluso hice referencia al 'Intel Power Gadget' en mi solicitud ya que utiliza instrucciones MSR similares a las de Volta.

No creo que a Apple le guste la idea de que los usuarios controlen su hardware. Especialmente cuando el undervolting puede causar problemas de estabilidad.

Por lo tanto, parece que si quieres instalar un kext no bendecido por Apple, no tienes más remedio que desactivar el SIP. Parece que Apple, a través de algún enrevesado razonamiento, piensa que estaré más seguro si, para ejecutar un código que ellos no aprueban, también tengo que abrir un enorme agujero en la seguridad de mi ordenador en el proceso.

1voto

KM. Puntos 51800

Parece que la extensión del núcleo no está firmada correctamente. Ejecute el siguiente script en su terminal y envíe el resultado a Volta:

codesign --display --verbose=4 /Aplicaciones/Volta.app/Contenidos/Recursos/Controlador.kext

Deberían poder comprobar la autoridad y si la extensión del kernel está firmada con su teamID. No estoy trabajando en Volta pero esto debería ser suficiente.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X