Una forma de controlar si las aplicaciones son realmente lo que son y no han sido modificadas es la gestión de firmado de código. Cuando se crea una aplicación para Mac, generalmente el desarrollador añade una ID específica al código que lo firma con sus credenciales del programa de desarrolladores. Estas credenciales son únicas y lo identifican y además, si el código de la aplicación ha sido modificado, este firmado de código se rompe, lo que además puede causar el mal funcionamiento, inestabilidad o incluso que la aplicación simplemente no arranque ya que el sistema verifica este firmado de código en busca de inconsistencias. De hecho, Gatekeeper utiliza este firmado de código para dar paso a las aplicaciones y permitir que se puedan iniciar en el Mac o no la primera vez que las arrancas.
Vamos a trabajar con el firmado de código de forma manual, aprendiendo como verificar si una aplicación está correctamente firmada. Para ello utilizaremos el Terminal, en Aplicaciones > Utilidades y empezaremos con el comando más básico:
codesign --verify --verbose /ruta/a/la/app/aplicación.app
Lo más fácil es añadir la primera parte del comando y luego, para sacar la ruta, arrastrar la aplicación a la ventana del Terminal para que la ruta se añada sola. Ahora pulsa retorno de carro para iniciar la verificación.
Si todo ha ido bien recibirás un mensaje similar a este:
Dalek:~ Dalek$ codesign --verify --verbose /Applications/App\ Store.app /Applications/App Store.app: valid on disk /Applications/App Store.app: satisfies its Designated Requirement
Donde valid on disk y satisfies its Designated Requirement nos están indicando que se ha pasado la prueba de firmado de código y la aplicación es legítima y no habido modificada.
Si la aplicación ha sido modificada o se le han añadido componentes, recibiremos un mensaje como este:
$ codesign --verify --verbose /Applications/Safari.app
/Applications/Safari.app: a sealed resource is missing or invalid
file added: /Applications/Safari.app/Contents/ASDF/nefariousfile.sh
Lo que nos está indicando que hay un problema y el correspondiente archivo que ha sido añadido, en este caso, un script: /Applications/Safari.app/Contents/ASDF/nefariousfile.sh y evidentemente, hay que deshacerse de esa aplicación a toda velocidad.
Además de la validación del código, también puedes utilizar las propias políticas de validación de las aplicaciones del sistema. Volvemos al Terminal y usamos el comando (con Safari de ejemplo, debes añadir la ruta a la aplicación que quieras inspeccionar):
spctl --assess --verbose /Applications/Safari.app
Que te devolverá la respuesta:
/Applications/Safari.app: accepted source=Apple System
Si la aplicación no pasa el corte hay muchas razones para ello, como por ejemplo, la ausencia del firmado de código, recursos de la aplicación obsoletos, falta de recursos o recursos inválidos entre otras muchas.
Ten encuesta que si has dado permiso a una aplicación para ser ejecutada sobrepasando las restricciones de Gatekeeper. Podrá ejecutarse incluso cuando no esté firmada, por lo que si posteriormente haces una revisión de la aplicación en busca de la firma te encontrarás con advertencias al respecto.
Para evitar tener que hacer este paso con cada una de las aplicaciones disponibles en tu Mac, lo mejor es realizar una búsqueda que lo haga por ti para que luego puedas investigar los resultados y localizar las aplicaciones potencialmente peligrosas o que simplemente son antiguas y no están firmadas.
Para el firmado del código usaremos el siguiente comando en el terminal:
find /Applications -d 1 -name "*.app" -exec codesign --verify --verbose {} \;
Mientras que para la evaluación de las políticas del sistema usaremos:
find /Applications -d 1 -name "*.app" -exec spctl --assess --verbose {} \;
Cuando se ejecutan ambos comandos, la salida de información puede ser muy grande, así que quizás debas redimensionar la ventana del Terminal e ir desplazándote por la ventana para comprobar cada aplicación.
Vía Macissues
Hola, Carlos: Me parece muy valioso tu artículo. Me parece que amplía lo que explicas al respecto en tu libro. He ejecutado en el Terminal el comando que evalúa el firmado de código de todas las aplicaciones y la información que ofrece como resultado es estupendo. En mi caso, es muy clara la indicación de las aplicaciones obsoletas, por ejemplo, entre las más conocidas y utilizadas: a) «StuffIt Expander.app: resource envelope is obsolete (custom omit rules)»; b) «Adobe Reader.app: resource envelope is obsolete (version 1 signature)». Cabe suponer que, eventualmente, los Desarrolladores de estas aplicaciones actualizarán el firmado del código. Sin embargo, no me queda muy claro cuando «hay que deshacerse de esa aplicación a toda velocidad», como dices textualmente. Por ejemplo: 1) «VLC.app: a sealed resource is missing or invalid file added: /Applications/VLC.app/Contents/MacOS/plugins/plugins.dat»; 2) «SuperDuper!.app: a sealed resource is missing or invalid file added: /Applications/SuperDuper!.app/Contents/Resources/Copy Scripts/Safety clone – shared users and applications.dset; file added: /Applications/SuperDuper!.app/Contents/Resources/Copy Scripts/Safety clone – shared users.dset; file modified: /Applications/SuperDuper!.app/Contents/Resources/Scripts/shutdown.scpt». Esta última aplicación es muy importante para mí, porque la utilizo para clonar el disco duro de mi MacBook Pro. Los scripts me resultan familiares y no me parecen peligrosos, hasta el punto de «deshacerme de la aplicación a toda velocidad». Según el desarrollador de la aplicación, SupeDuper!.app ya está actualizada para El Capitan. Te agradecería mucho si puedes ampliar tu comentario para darnos un criterio general que nos permita decidir más claramente sobre estos casos. Un cordial saludo y muchas gracias por tu excelente trabajo.
Hola Vicente:
Gracias por tus comentarios.
Vamos por partes:
– Resulta evidente que si una aplicación ha sido descargada desde la web del desarrollador y da “algún error” depende mucho de los ciclos de actualización del propio desarrollador para adaptarse al firmado de código. Me sorprende mucho que Adobe Reader todavía no se haya actualizado al esquema de nuevas firmas cuando es “obligatorio” por parte de Apple (evidentemente para software distribuido en la Mac App Store).
– En general, este tipo de problemas requiere del propio análisis del usuario sobre todo cuando se trata de aplicaciones fuera de la Mac App Store. En el caso de SuperDuper, como supongo que serás usuario registrado, me pondría en contacto con el desarrollador para comentar los resultados del proceso, pero si descargaste la aplicación y las actualizaciones desde la propia web del desarrollador estos errores no deberían ser un problema.
– El gran problema, el más gordo, es para aquellas personas que descargan aplicaciones desde servicios P2P, descargas desde web de dudosa procedencia o incluso directorios supuestamente legítimos como softonic o download.com que te enchufan, junto con la aplicación, Adware. Es precisamente por este problema por el que hay que realizar un análisis de las aplicaciones, su firma y los posibles problemas causados por la modificación del código del mismo, generalmente, a espaldas del desarrollador.
Y muchas gracias otra vez. 😉
Te agradezco tu amable respuesta, Carlos. Un cordial saludo.
Sería muy interesante que, en una próxima ocasión, volvieras sobre el asunto del TRIM de los SSD que, según informaste en un artículo de hace varias jornadas, ha sido modificado en El Capitan. Al parecer, no se utiliza el mismo procedimiento que en Yosemite. Sería muy útil que nos indicaras un comando para utilizarlo en el Terminal para COMPROBAR si el TRIM está activado o SIGUE ACTIVADO después de cada actualización de sistema. Como entenderás, el tema es de primordial interés para todos los usuarios de SSD y de El Capitan. Muy agradecido por tus excelentes servicios a la comunidad Mac.
Esta semana retomo el tema del TRIM.
Un abrazo y gracias